ALLEGATO

Specifica tecnica di interoperabilità per il sottosistema Applicazioni telematiche per il trasporto merci del sistema ferroviario transeuropeo convenzionale

INDICE

1.	INTRODUZIONE

1.1.	Campo di applicazione tecnico

1.2.	Campo di applicazione geografico

1.3.	Contenuto della STI

2.	DEFINIZIONE DEL SOTTOSISTEMA/CAMPO DI APPLICAZIONE

2.1.	Funzioni comprese nel campo di applicazione della STI

2.2.	Funzioni non comprese nel campo di applicazione della STI

2.3.	Principali elementi della descrizione del sottosistema

2.3.1.

Soggetti interessati

2.3.2.

Processi presi in considerazione

2.3.3.

Note generali

3.	REQUISITI ESSENZIALI

3.1.	Conformità ai requisiti essenziali

3.2.	Aspetti dei requisiti essenziali

3.3.	Aspetti in relazione ai requisiti generali

3.3.1.

Sicurezza

3.3.2.

Affidabilità e disponibilità

3.3.3.

Salute

3.3.4.

Tutela dell'ambiente

3.3.5.

Compatibilità tecnica

3.4.	Aspetti legati in modo specifico al sottosistema Applicazioni telematiche per il trasporto merci

3.4.1.

Compatibilità tecnica

3.4.2.

Affidabilità e disponibilità

3.4.3.

Salute

3.4.4.

Sicurezza

4.	CARATTERISTICHE DEL SOTTOSISTEMA

4.1.	Introduzione

4.2.	Specifiche funzionali e tecniche del sottosistema

4.2.1.

Dati della lettera di vettura

4.2.2.

Richiesta di traccia oraria

4.2.3.

Preparazione del treno

4.2.4.

Previsione di marcia del treno

4.2.5.

Informazioni concernenti la perturbazione del servizio

4.2.6.

Posizione del treno

4.2.7.

ETI/ETA della spedizione

4.2.8.

Movimenti del carro

4.2.9.

Comunicazioni di interscambio

4.2.10.

Scambio di dati a fini di miglioramento della qualità

4.2.11.

Principali dati di riferimento

4.2.12.

Archivi di riferimento e banche dati varie

4.2.13.

Trasmissione elettronica dei documenti

4.2.14.

Reti e comunicazioni

4.3.	Specifiche funzionali e tecniche delle interfacce

4.3.1.

Interfacce con la STI Infrastruttura

4.3.2.

Interfacce con la STI Controllo/comando e segnalamento

4.3.3.

Interfacce con il sottosistema Materiale rotabile

4.3.4.

Interfacce con la STI Esercizio e gestione del traffico

4.4.	Norme operative

4.4.1.

Qualità dei dati

4.4.2.

Gestione del repository centrale

4.5.	Norme di manutenzione

4.6.	Qualifiche professionali

4.7.	Requisiti di igiene e sicurezza sul lavoro

4.8.	Registri dell'infrastruttura e del materiale rotabile

5.	COMPONENTI DI INTEROPERABILITÀ

5.1.	Definizione

5.2.	Elenco dei componenti

5.3.	Prestazioni e specifiche dei componenti

6.	VALUTAZIONE DELLA CONFORMITÀ E/O IDONEITÀ ALL'USO DEI COMPONENTI E VERIFICA DEL SOTTOSISTEMA

6.1.	Componenti di interoperabilità

6.1.1.

Procedure di valutazione

6.1.2.

Modulo

6.2.	Sottosistema Applicazioni telematiche per il trasporto merci

7.	APPLICAZIONE

7.1.	Modalità di applicazione della presente STI

7.1.1.

Introduzione

7.1.2.

Piano strategico europeo di attuazione (PSEA)

7.1.3.

Modalità di applicazione

7.2.	Strategia di migrazione

7.3.	Gestione del cambiamento

7.3.1.

Introduzione

7.3.2.

Baseline

7.3.3.

Rilascio delle baseline

7.3.4.

Introduzione delle nuove baseline

7.3.5.

Processo di gestione del cambiamento — requisiti

7.3.6.

Piano di gestione della configurazione — requisiti

7.4.	Casi specifici

7.4.1.

Introduzione

7.4.2.

Elenco dei casi specifici

ALLEGATO A

ELENCO DEI DOCUMENTI ACCOMPAGNATORI

ALLEGATO B

GLOSSARIO

TABELLE:

Tabella 1:

Richiesta di traccia oraria

Tabella 2:

Annullamento di traccia oraria da parte dell'IF

Tabella 3:

Soppressione di traccia oraria da parte del GI

Tabella 4:

Conferma di ricevimento

Tabella 5:

Preparazione del treno

Sistema ferroviario transeuropeo convenzionale

Specifica tecnica di interoperabilità Sottosistema Applicazioni telematiche per il trasporto merci

1.   INTRODUZIONE

1.1.   Campo di applicazione tecnico

La presente STI si applica al sottosistema Applicazioni telematiche per il trasporto merci, che figura nell'elenco di cui all'allegato II, paragrafo 1, lettera b), della direttiva 2001/16/CE.

L'esercizio commerciale di treni, carri e unità intermodali lungo la rete ferroviaria transeuropea presuppone uno scambio efficiente di informazioni tra i gestori dell'infrastruttura, le imprese ferroviarie e gli altri soggetti erogatori di servizi. Dalla compatibilità e dallo scambio di informazioni dipendono il livello delle prestazioni, la sicurezza, la qualità e il costo dei servizi, nonché, in modo particolare, l'interoperabilità del sistema ferroviario transeuropeo convenzionale.

La specifica tecnica di interoperabilità influenza anche le condizioni di utilizzo del trasporto ferroviario da parte degli utenti. In questo contesto, per «utenti» si intendono non solo i gestori dell'infrastruttura o le imprese ferroviarie, ma anche tutti gli altri soggetti erogatori di servizi quali le imprese di gestione dei carri e gli operatori intermodali, come pure i clienti.

Nella redazione della STI si è tenuto conto anche di un altro aspetto importante, vale a dire il beneficio derivante dall'interoperabilità del sistema ferroviario convenzionale ai fini della creazione delle condizioni per una migliore interoperabilità intermodale, in particolare fra il trasporto ferroviario convenzionale e il trasporto ferroviario combinato.

L'obiettivo di questa STI è assicurare uno scambio di informazioni efficiente e capace di adeguarsi sempre in maniera ottimale, sia nella qualità che nella quantità, al mutare delle esigenze, di modo da garantire quanto più possibile l'efficienza economica del processo di trasporto e la competitività del trasporto merci su rotaia malgrado la forte concorrenza.

A tal fine, sarà necessario realizzare o ristrutturare il sistema ferroviario transeuropeo convenzionale per il trasporto ferroviario convenzionale e il trasporto intermodale. La necessità di ristrutturare la componente ferroviaria del sistema di trasporto risulta evidente anche considerando i punti critici (interfacce tra i vari soggetti partecipanti) del trasporto merci su strada rispetto ai punti critici del trasporto merci su rotaia in uno scenario semplificato, illustrato nel documento 5, paragrafo 1.1, di cui all'allegato A.

L'obiettivo fondamentale di questa STI è assicurare, attraverso lo scambio di informazioni, la gestione delle spedizioni in presenza di un numero tanto elevato di interfacce secondo quanto previsto dalle direttive del Parlamento europeo e del Consiglio 2001/14/CE (1) e 2001/16/CE.

Già in questa sintetica spiegazione del campo di applicazione della STI Applicazioni telematiche per il trasporto merci nel sistema ferroviario convenzionale è possibile cogliere le differenze rispetto alla STI Esercizio e gestione del traffico nel sistema ferroviario convenzionale. Quest'ultima si applica, in particolare per quanto riguarda gli aspetti legati alla sicurezza, alle procedure e alle apparecchiature e attrezzature associate che permettono di garantire un funzionamento coerente dei diversi sottosistemi strutturali, tra cui la condotta dei treni, la pianificazione e la gestione del traffico, che rappresentano l'attività principale di un'IF in base alla definizione ad essa relativa (cfr. paragrafo 2.3: Principali elementi della descrizione del sottosistema).

La STI Applicazioni telematiche riguarda invece le applicazioni per il trasporto merci e la gestione delle coincidenze con altri modi di trasporto, quindi si applica ai servizi di trasporto delle IF, oltre che alla pura e semplice circolazione dei treni. Essa tiene conto degli aspetti legati alla sicurezza della circolazione solo nei casi in cui dall'esistenza di dati errati o non aggiornati possono scaturire conseguenze sulla sicurezza di un treno in circolazione.

1.2.   Campo di applicazione geografico

Il campo di applicazione geografico della presente STI coincide con il sistema ferroviario transeuropeo convenzionale di cui all'allegato I della direttiva 2001/16/CE. La presente STI può essere applicata anche a tutta la rete ferroviaria per il trasporto merci degli Stati membri dell'UE, ma i requisiti in essa contenuti non hanno valore obbligatorio per il trasporto di merci in provenienza da o a destinazione di un paese non appartenente all'UE.

1.3.   Contenuto della STI

Come previsto all'articolo 5, paragrafo 3, della direttiva 2001/16/CE, la presente STI:

a)	definisce l'ambito di applicazione previsto del sottosistema Applicazioni telematiche per il trasporto merci — capitolo 2: Definizione del sottosistema/campo di applicazione;

b)	precisa i requisiti essenziali del sottosistema e delle interfacce verso gli altri sottosistemi — capitolo 3: Requisiti essenziali;

c)	definisce le specifiche funzionali e tecniche del sottosistema e delle interfacce verso gli altri sottosistemi — capitolo 4: Caratteristiche del sottosistema;

d)	determina i componenti di interoperabilità e le interfacce oggetto di specifiche europee, tra cui le norme europee, necessari per realizzare l'interoperabilità del sistema ferroviario transeuropeo convenzionale — capitolo 5: Componenti di interoperabilità;

e)

indica, in ogni caso previsto, le procedure di valutazione della conformità o dell'idoneità all'impiego. Ciò comporta in particolare i moduli definiti nella decisione 93/465/CEE del Consiglio (2) o, se del caso, le procedure specifiche da usare, per valutare la conformità o l'idoneità all'impiego dei componenti di interoperabilità, nonché la verifica «CE» dei sottosistemi — capitolo 6: Valutazione della conformità e/o idoneità all'uso dei componenti e verifica del sottosistema;

f)	indica la strategia di attuazione della STI, precisando in particolare le fasi da superare per passare progressivamente dalla situazione attuale alla situazione finale di rispetto generalizzato della STI — capitolo 7: Applicazione;

g)	indica, per il personale interessato, i requisiti di qualifica professionale e di igiene e sicurezza sul luogo di lavoro richiesti per il funzionamento e la manutenzione del sottosistema nonché per l'attuazione della STI — capitolo 4: Caratteristiche del sottosistema.

Inoltre, conformemente all'articolo 5, paragrafo 5, la STI prevede disposizioni relative a casi specifici; tali disposizioni sono contenute nel paragrafo 7.4: Casi specifici.

Infine, la STI indica anche, nel capitolo 4 (Caratteristiche del sottosistema), i requisiti operativi e di manutenzione legati in modo specifico al campo di applicazione descritto ai paragrafi 1.1(Campo di applicazione tecnico) e 1.2 (Campo di applicazione geografico).

2.   DEFINIZIONE DEL SOTTOSISTEMA/CAMPO DI APPLICAZIONE

2.1.   Funzioni comprese nel campo di applicazione della STI

La definizione del sottosistema Applicazioni telematiche per il trasporto merci è contenuta nell'allegato II, paragrafo 2.5, lettera b), della direttiva 2001/16/CE.

Il sottosistema comprende in particolare:

—	le applicazioni per il trasporto merci, compresi i sistemi di informazione (controllo in tempo reale delle merci e dei treni),

—	i sistemi di smistamento e destinazione, dove per destinazione si intende la composizione del treno,

—	i sistemi di prenotazione, dove per prenotazione si intende prenotazione delle tracce orarie,

—	la gestione delle coincidenze con altri modi di trasporto e la produzione dei documenti elettronici di accompagnamento.

2.2.   Funzioni non comprese nel campo di applicazione della STI

Nel campo di applicazione di questa STI non sono compresi né i sistemi di pagamento e fatturazione per i clienti, né i sistemi di pagamento e fatturazione tra soggetti erogatori di servizi quali imprese ferroviarie o gestori dell'infrastruttura. Tuttavia, la struttura del sistema di scambio dati, descritta nel capitolo 4.2 (Specifiche funzionali e tecniche del sottosistema), permette di ricavare le informazioni di base necessarie per il pagamento dei servizi di trasporto.

Anche la pianificazione a lungo termine degli orari esula dal campo di applicazione della STI sulle applicazioni telematiche. In alcuni punti, tuttavia, ove sia rilevabile un rapporto con lo scambio efficiente di dati necessario per l'esercizio dei treni, viene fatto riferimento all'esito della pianificazione a lungo termine.

2.3.   Principali elementi della descrizione del sottosistema

2.3.1.   Soggetti interessati

La presente STI tiene conto dei soggetti erogatori di servizi che intervengono o potranno intervenire in futuro nel trasporto di merci per i seguenti aspetti (l'elenco non è tassativo):

—

carri

—	locomotive

—	macchinisti

—	operazioni di manovra

—	vendita di slot

—	gestione delle spedizioni

—	composizione dei treni

—	esercizio dei treni

—	monitoraggio dei treni

—	controllo dei treni

—	monitoraggio delle spedizioni

—	ispezioni e riparazioni di carri e/o locomotive

—	sdoganamento

—	esercizio dei terminali intermodali

—	gestione del trasporto su strada.

Per alcuni soggetti erogatori di servizi specifici, le direttive 2001/14/CE e 2001/16/CE riportano definizioni esplicite. Poiché è necessario tener conto di entrambe le direttive, la presente STI prende in considerazione in particolare la seguente definizione (cfr. anche allegato A, documento 6).

In base a questa definizione, la presente STI si applica ai GI in quanto soggetti erogatori di servizi per l'assegnazione di tracce orarie, il controllo/monitoraggio dei treni e le comunicazioni relative a treni/tracce orarie.

Conformemente alla direttiva 2001/14/CE, l'organismo o impresa a cui un GI assegna una traccia oraria è definito richiedente.

In base a questa definizione, la presente STI si applica alle IF in quanto soggetti erogatori di servizi per l'esercizio dei treni.

Per l'assegnazione delle tracce orarie necessarie per la circolazione dei treni, occorre tener conto anche dell'articolo 13 della direttiva 2001/14/CE.

In relazione agli scenari di comunicazione tra gestori dell'infrastruttura e richiedenti nella modalità di esecuzione di un trasporto, si deve tener conto soltanto del GI e dell'IF e non di tutti i tipi di richiedenti che invece potrebbero avere rilevanza nella modalità di pianificazione. Nella modalità di esecuzione è sempre indicato un rapporto tra GI e IF; la presente STI indica i messaggi che devono essere inviati e le informazioni che devono essere scambiate nell'ambito di tale rapporto. La definizione di richiedente e le risultanti possibilità di assegnazione delle tracce orarie rimangono inalterate.

Come già indicato in precedenza, il trasporto di merci richiede l'erogazione di vari servizi, ad esempio la fornitura di carri. Questo servizio può essere svolto da un gestore di parco rotabile. Se il servizio rientra tra quelli offerti da un'IF, allora l'IF svolge anche la funzione di gestore di parco rotabile. Un gestore di parco rotabile può gestire carri propri e/o di un altro titolare (altro soggetto erogatore di servizi per carri merci). Delle necessità di questo tipo di soggetto erogatore di servizi si tiene conto indipendentemente dal fatto che il gestore del parco rotabile sia un'IF oppure un soggetto giuridico diverso.

La presente STI non crea nuove figure giuridiche e non obbliga le IF a coinvolgere soggetti esterni per i servizi offerti dalle stesse IF; all'occorrenza, tuttavia, essa indica i servizi facendo riferimento al nome del soggetto erogatore corrispondente. Se il servizio è offerto da un'IF, l'IF svolge la funzione di soggetto erogatore del servizio.

Nel tener conto delle necessità dei clienti, uno dei servizi da offrire consiste nell'organizzare e gestire le linee di trasporto in base al principio dell'attenzione per il cliente. Questo servizio è svolto dall'«impresa ferroviaria responsabile» (IF responsabile o IFR). L'IFR funge da singolo punto di contatto per il cliente. Se alla catena di trasporto partecipano più imprese ferroviarie, l'IFR è responsabile anche del coordinamento con le altre imprese ferroviarie.

Questo servizio può essere svolto anche da uno spedizioniere o da qualsiasi altra figura.

Il coinvolgimento di un'IF in qualità di IFR può variare a seconda del tipo di flusso dei trasporti. Nei trasporti intermodali, la gestione della capacità dei treni blocco e la predisposizione dei titoli di trasporto sono demandati a un integratore di servizi intermodali, che quindi può essere un cliente dell'IFR.

Il punto essenziale, comunque, è che le IF, i GI e tutti gli altri soggetti erogatori di servizi (secondo la definizione riportata in precedenza) devono lavorare insieme, in cooperazione e/o accesso libero, nonché attraverso uno scambio efficiente di informazioni, per fornire al cliente servizi perfettamente integrati, senza soluzione di continuità.

2.3.2.   Processi presi in considerazione

Conformemente a quanto indicato nella direttiva 2001/16/CE, la presente STI sul trasporto merci a mezzo ferrovia si applica unicamente a GI e IF/IFR con riferimento ai loro clienti diretti.

Nell'esercizio dei servizi di trasporto merci l'attività di un'IFR, in relazione a un carico di merce, ha inizio con il ricevimento della lettera di vettura del cliente e, ad esempio, nel caso di spedizioni a carro completo, con l'orario di messa a disposizione dei carri. L'IFR crea un piano di inoltro preliminare (in base alla propria esperienza e/o a un contratto) per il percorso del trasporto. Se l'IFR intende inserire il carro completo in un treno secondo la modalità di accesso libero (in cui l'IFR gestisce il treno per l'intero percorso), il piano di inoltro preliminare coincide con il piano di inoltro definitivo. Se l'IFR intende inserire il carro completo in un treno gestito in cooperazione con altre IF, deve per prima cosa individuare le IF da interpellare e stabilire l'orario in cui può essere effettuato l'interscambio tra due IF successive. A quel punto, l'IFR predispone per ciascuna IF le richieste preliminari di carri, che costituiscono un sottoinsieme della lettera di vettura completa. Il contenuto delle richieste di carri è precisato nel paragrafo 4.2.1 (Dati della lettera di vettura).

Le IF interpellate verificano la disponibilità delle risorse necessarie per la circolazione dei carri, nonché la disponibilità della traccia oraria. In base alle risposte delle varie IF, l'IFR può perfezionare il piano di inoltro o ripetere la richiesta — estendendola eventualmente ad altre IF — fino a quando il piano di inoltro risulta conforme alle richieste del cliente.

In linea di massima, le IF/IFR devono essere in grado almeno di:

—

DEFINIRE i servizi in termini di prezzo e orari di transito, fornitura dei carri (se del caso), informazioni sui carri/unità intermodali (ubicazione, stato e orario previsto di arrivo — ETA — dei carri/unità intermodali), luogo in cui è possibile effettuare il carico delle merci sui carri vuoti, container, ecc.,

—

EROGARE il servizio definito in maniera affidabile e senza soluzione di continuità, utilizzando procedure operative comuni e sistemi correlati. Le IF, i GI e gli altri erogatori di servizi e soggetti interessati, quali ad esempio le dogane, devono essere in grado di scambiarsi dati in formato elettronico,

—	MISURARE la qualità del servizio erogato rispetto al servizio definito, verificando ad esempio la corrispondenza tra importi fatturati e preventivati, tra orari di transito effettivi e teorici, tra carri richiesti e forniti, tra ETA e orari effettivi di arrivo,

—	OPERARE in modo produttivo in termini di utilizzo: capacità di treni, infrastruttura e parchi rotabili attraverso l'uso di procedure operative, sistemi e scambi di dati necessari per consentire la corretta programmazione di carri/unità intermodali e treni.

Le IF/IFR, in quanto richiedenti, devono anche effettuare le tracce orarie richieste (sulla base di contratti con i GI) e far circolare i treni entro le sezioni del percorso di loro competenza. A tal fine possono usare tracce già prenotate (nella modalità di pianificazione), oppure richiedere una traccia ad hoc al gestore o ai gestori dell'infrastruttura (GI) competenti per le sezione o le sezioni del percorso su cui l'IF gestisce il treno. Nel documento 5, paragrafo 1.2, di cui all'allegato A, è riportato l'esempio di un ipotetico scenario di richiesta di traccia.

L'appartenenza della traccia oraria è importante anche per le comunicazioni tra GI e IF durante la circolazione del treno. Le comunicazioni devono sempre basarsi sul numero di treno e sul numero di traccia; il GI comunica con l'IF che ha prenotato la traccia sull'infrastruttura da esso gestita (cfr. anche documento 5, paragrafo 1.2, di cui all'allegato A).

Se un'IF provvede a far circolare il treno sull'intero percorso A-F (accesso libero, nessun'altra IF coinvolta nel processo), ciascun GI competente comunica direttamente soltanto con tale IF. Per far circolare il treno in accesso libero, l'IF può prenotare la traccia per mezzo dello sportello unico oppure rivolgersi direttamente ai vari GI per le sezioni di rispettiva competenza. La presente STI prende in considerazione entrambi i casi, così come indicato al paragrafo 4.2.2.1: Richiesta di traccia oraria, Note preliminari.

Il dialogo tra le IF e i GI per la definizione della traccia per un treno merci è descritto al paragrafo 4.2.2 (Richiesta di traccia oraria). Questa funzione si richiama all'articolo 23, paragrafo 1, della direttiva 2001/14/CE. Il dialogo per la definizione della traccia non è collegato in alcun modo all'ottenimento della licenza per le IF che forniscono servizi a norma della direttiva 2001/13/CE del Parlamento europeo e del Consiglio (3), alla certificazione a norma della direttiva 2001/14/CE e ai diritti di accesso a norma della direttiva 91/440/CEE del Consiglio (4).

Il paragrafo 4.2.3 (Preparazione del treno) descrive lo scambio di informazioni riguardanti la composizione di un treno e la procedura di partenza dello stesso. Lo scambio di dati durante la marcia di un treno in condizioni normali è precisato al paragrafo 4.2.4 (Previsione di marcia del treno); i messaggi in caso di imprevisti sono definiti al paragrafo 4.2.5 (Informazioni concernenti la perturbazione del servizio). Le informazioni riguardanti la localizzazione dei treni sono contenute nel paragrafo 4.2.6 (Posizione del treno). Tutti questi messaggi vengono scambiati tra IF e GI e riguardano il treno specifico di volta in volta identificato.

Per un cliente, l'informazione più importante è sempre l'orario previsto di arrivo (ETA) della spedizione. Nella modalità di accesso libero, l'ETA si può calcolare in base ai dati che si scambiano l'IFR e il GI. Nella modalità di cooperazione con varie IF, l'ETA e gli orari previsti di interscambio (ETI) si possono ricavare dai messaggi che si scambiano IF e GI; sono forniti all'IFR dalle IF (paragrafo 4.2.7: ETI/ETA della spedizione).

In base alle informazioni scambiate tra GI e IF, l'IFR è in grado di stabilire anche, ad esempio:

—	l'orario di partenza o di arrivo dei carri in un piazzale o in punti specificati (paragrafo 4.2.8: Movimenti del carro), oppure

—	il momento in cui si attua il passaggio di responsabilità da un'IF all'IF successiva della catena di trasporto (paragrafo 4.2.9: Comunicazioni di interscambio).

In base allo scambio di dati non solo tra il GI e l'IF ma anche tra le varie IF e l'IFR, è possibile calcolare dati statistici allo scopo di:

—	eseguire una pianificazione a medio termine più particolareggiata del processo di produzione,

—	eseguire una pianificazione strategica a lungo termine e studi sulla capacità (ad es. analisi della rete, definizione dei raccordi e dei piazzali di smistamento, pianificazione del materiale rotabile), ma soprattutto

—	migliorare la qualità del servizio di trasporto e la produttività (paragrafo 4.2.10: Scambio di dati a fini di miglioramento della qualità).

La circolazione dei carri vuoti assume una particolare rilevanza nel caso dei carri interoperabili. In linea di principio non ci sono differenze tra la circolazione di carri carichi e la circolazione di carri vuoti. Anche nel trasporto dei carri vuoti il processo ha come elemento centrale la richiesta di carri; in questo caso il cliente è rappresentato dal gestore del parco rotabile.

2.3.3.   Note generali

La bontà di un sistema informativo è strettamente legata all'affidabilità dei dati che vi sono contenuti. Pertanto, i dati che svolgono una funzione decisiva ai fini dell'inoltro di un carico, carro o container devono rispondere a criteri di accuratezza ed essere acquisiti in modo economicamente efficiente, cioè essere immessi nel sistema una sola volta.

In base a questo principio, le applicazioni e i messaggi della presente STI evitano la duplicazione dell'immissione manuale dei dati prevedendo l'accesso ai dati già esistenti, ad esempio i dati di riferimento sul materiale rotabile. I requisiti relativi ai dati di riferimento sul materiale rotabile sono indicati al paragrafo 4.2.11 (Principali dati di riferimento). Le banche dati di riferimento sul materiale rotabile devono permettere di accedere agevolmente ai dati tecnici. Al contenuto delle banche dati devono poter accedere, in base a diritti di accesso strutturati in funzione dei privilegi, tutti i GI, le IF e i gestori di parchi rotabili, in particolare per finalità connesse alla gestione dei parchi rotabili e alla manutenzione dei rotabili. Le banche dati devono contenere tutti i dati tecnici di importanza cruciale per il trasporto, ad esempio:

—	dati identificativi del materiale rotabile,

—	dati tecnico-progettuali,

—	valutazione della compatibilità con l'infrastruttura,

—	valutazione delle caratteristiche di caricamento pertinenti,

—	caratteristiche dei freni pertinenti,

—	dati sulla manutenzione,

—	caratteristiche ambientali.

Nel trasporto intermodale esistono terminali (i cosiddetti gateway) in cui si effettua il trasferimento non solo di carri da un treno a un altro, ma anche di unità intermodali da un carro a un altro. Di conseguenza, non è possibile operare soltanto con un piano di inoltro per i carri; occorre predisporre un piano di inoltro anche per le unità intermodali.

Nel paragrafo 4.2.12 (Archivi di riferimento e banche dati varie) è riportato un elenco di archivi e banche dati varie, tra cui la banca dati operativa dei carri e delle unità intermodali. Tale banca dati contiene i dati sullo stato operativo del materiale rotabile, informazioni sul peso e sulle merci pericolose, informazioni relative alle unità intermodali e informazioni sull'ubicazione. Nel paragrafo 4.2.13 (Trasmissione elettronica dei documenti) sono indicati i requisiti riguardanti la trasmissione elettronica dei documenti.

La STI relativa al sottosistema Applicazioni telematiche per il trasporto merci definisce le informazioni che devono scambiarsi i vari soggetti partecipanti alla catena di trasporto e permette di realizzare un processo standard di scambio dei dati obbligatori. La STI illustra inoltre la strategia relativa all'architettura della piattaforma di comunicazione. Tale architettura è definita al paragrafo 4.2.14 (Reti e comunicazioni) tenendo conto dei seguenti elementi:

—	interfaccia verso il sottosistema Esercizio e gestione del traffico del sistema ferroviario transeuropeo convenzionale a norma dell'articolo 5, paragrafo 3, della direttiva 2001/16/CE,

—	requisiti relativi al contenuto del prospetto informativo della rete, indicati nella direttiva 2001/14/CE, articolo 3 e allegato I,

—	informazioni disponibili sul materiale rotabile adibito al trasporto di merci e requisiti riguardanti la manutenzione contenuti nella STI Materiale rotabile.

Non è prevista la trasmissione diretta di dati dal sottosistema Applicazioni telematiche per il trasporto merci al treno, al macchinista o a componenti del sottosistema Controllo-comando e segnalamento, e la rete fisica di trasmissione è completamente diversa dalla rete usata da quest'ultimo sottosistema. Il sistema ERTMS/ETSC utilizza il GSM-R. In tale rete aperta le specifiche ETCS precisano che la sicurezza è assicurata attraverso la corretta gestione dei pericoli delle reti aperte nel protocollo EURORADIO.

Le interfacce verso i sottosistemi strutturali Materiale rotabile e Controllo-comando si realizzano soltanto attraverso le banche dati di riferimento sul materiale rotabile (paragrafo 4.2.11.3: Banche dati di riferimento sul materiale rotabile), poste sotto il controllo dei titolari. Le interfacce verso i sottosistemi Infrastrutture, Controllo-comando ed Energia si realizzano con la definizione delle tracce (paragrafo 4.2.2.3: Messaggio Dettagli della traccia oraria) da parte del GI, che specifica i valori legati all'infrastruttura per le caratteristiche del treno, e con le informazioni fornite dai GI riguardo alle restrizioni dell'infrastruttura (paragrafo 4.2.11.2: Banche dati degli avvisi di restrizione dell'infrastruttura).

3.   REQUISITI ESSENZIALI

3.1.   Conformità ai requisiti essenziali

Ai sensi dell'articolo 4, paragrafo 1, della direttiva 2001/16/CE, il sistema ferroviario transeuropeo convenzionale, i sottosistemi e i componenti di interoperabilità devono soddisfare i requisiti essenziali indicati in termini generali nell'allegato III della medesima direttiva.

Nell'ambito della presente STI, la conformità ai requisiti essenziali pertinenti indicati nel capitolo 3 della STI sarà assicurata per il sottosistema dalla conformità alle specifiche riportate nel capitolo 4: Caratteristiche del sottosistema.

3.2.   Aspetti dei requisiti essenziali

I requisiti essenziali riguardano i seguenti aspetti:

—	sicurezza,

—	affidabilità e disponibilità,

—

salute,

—	tutela dell'ambiente,

—	compatibilità tecnica.

A norma della direttiva 2001/16/CE, i requisiti essenziali possono riguardare in generale l'intero sistema ferroviario transeuropeo convenzionale o essere specifici per ogni sottosistema e relativi componenti.

3.3.   Aspetti in relazione ai requisiti generali

L'applicabilità dei requisiti generali al sottosistema Applicazioni telematiche per il trasporto merci è determinata nel modo seguente.

3.3.1.   Sicurezza

A norma dell'allegato III della direttiva 2001/16/CE, i requisiti essenziali legati alla sicurezza che si applicano al sottosistema Applicazioni telematiche per il trasporto merci sono i seguenti.

—

Requisito essenziale 1.1.1 di cui all'allegato III della direttiva 2001/16/CE: «La progettazione, la costruzione o la fabbricazione, la manutenzione e la sorveglianza dei componenti critici per la sicurezza e, più in particolare, degli elementi che partecipano alla circolazione dei treni devono garantire la sicurezza ad un livello corrispondente agli obiettivi fissati sulla rete, anche in situazioni specifiche di degrado.» Questo requisito essenziale non si applica al sottosistema Applicazioni telematiche.

—

Requisito essenziale 1.1.2 di cui all'allegato III della direttiva 2001/16/CE: «I parametri legati al contatto ruota-rotaia devono rispettare i criteri di stabilità di passaggio necessari per garantire una circolazione in piena sicurezza alla velocità massima autorizzata.» Questo requisito essenziale non si applica al sottosistema Applicazioni telematiche.

—

Requisito essenziale 1.1.3 di cui all'allegato III della direttiva 2001/16/CE: «I componenti utilizzati devono resistere alle sollecitazioni normali o eccezionali specificate per tutta la loro durata di servizio. Il mancato funzionamento accidentale deve essere limitato nelle sue conseguenze per la sicurezza mediante opportuni mezzi.» Questo requisito essenziale non si applica al sottosistema Applicazioni telematiche.

—

Requisito essenziale 1.1.4 di cui all'allegato III della direttiva 2001/16/CE: «La progettazione degli impianti fissi e del materiale rotabile nonché la scelta dei materiali utilizzati devono aver luogo in modo da limitare la generazione, la propagazione e gli effetti del fuoco e dei fumi in caso di incendio.» Questo requisito essenziale non si applica al sottosistema Applicazioni telematiche.

—

Requisito essenziale 1.1.5 di cui all'allegato III della direttiva 2001/16/CE: «I dispositivi destinati ad essere manovrati dagli utenti devono essere progettati in modo da non compromettere l'utilizzazione sicura dei dispositivi né la salute o la sicurezza degli utenti in caso di uso prevedibile non conforme alle istruzioni indicate.» Questo requisito essenziale non si applica al sottosistema Applicazioni telematiche.

3.3.2.   Affidabilità e disponibilità

La conformità a questo requisito essenziale è assicurata dai seguenti paragrafi:

4.2.11: Principali dati di riferimento,

4.2.12: Archivi di riferimento e banche dati varie,

4.2.14: Reti e comunicazioni.

3.3.3.   Salute

—

Requisito essenziale 1.3.1 di cui all'allegato III della direttiva 2001/16/CE: «I materiali che, quando utilizzati, potrebbero mettere in pericolo la salute delle persone che vi hanno accesso non devono essere utilizzati nei treni e nelle infrastrutture ferroviarie.» Questo requisito essenziale non si applica al sottosistema Applicazioni telematiche.

—

Requisito essenziale 1.3.2 di cui all'allegato III della direttiva 2001/16/CE: «La scelta, l'impiego e l'utilizzazione di questi materiali devono aver luogo in modo da limitare l'emissione di fumi o di gas nocivi e pericolosi, soprattutto in caso di incendio.» Questo requisito essenziale non si applica al sottosistema Applicazioni telematiche.

3.3.4.   Tutela dell'ambiente

—

Requisito essenziale 1.4.1 di cui all'allegato III della direttiva 2001/16/CE: «L'impatto ambientale legato alla realizzazione e all'esercizio del sistema ferroviario transeuropeo convenzionale deve essere valutato e considerato al momento della progettazione del sistema secondo le disposizioni comunitarie vigenti.» Questo requisito essenziale non si applica al sottosistema Applicazioni telematiche.

—

Requisito essenziale 1.4.2 di cui all'allegato III della direttiva 2001/16/CE: «I materiali utilizzati nei treni e nelle infrastrutture devono evitare l'emissione di fumi o di gas nocivi e pericolosi per l'ambiente, soprattutto in caso di incendio.» Questo requisito essenziale non si applica al sottosistema Applicazioni telematiche.

—

Requisito essenziale 1.4.3 di cui all'allegato III della direttiva 2001/16/CE: «Il materiale rotabile e i sistemi di alimentazione di energia devono essere progettati e realizzati per essere compatibili, in materia elettromagnetica, con gli impianti, le apparecchiature e le reti pubbliche o private con cui rischiano di interferire.» Questo requisito essenziale non si applica al sottosistema Applicazioni telematiche.

—	Requisito essenziale 1.4.4 di cui all'allegato III della direttiva 2001/16/CE: «L'esercizio del sistema ferroviario europeo convenzionale deve rispettare i livelli regolamentari in materia di rumore.» Questo requisito essenziale non si applica al sottosistema Applicazioni telematiche.

—

Requisito essenziale 1.4.5 di cui all'allegato III della direttiva 2001/16/CE: «L'esercizio del sistema ferroviario europeo convenzionale non deve provocare nel suolo un livello di vibrazioni inaccettabile per le attività e l'ambiente attraversato nelle vicinanze dell'infrastruttura e in stato normale di manutenzione.» Questo requisito essenziale non si applica al sottosistema Applicazioni telematiche.

3.3.5.   Compatibilità tecnica

—

Requisito essenziale 1.5 di cui all'allegato III della direttiva 2001/16/CE: «Le caratteristiche tecniche delle infrastrutture e degli impianti fissi devono essere compatibili tra loro e con quelle dei treni destinati a circolare sul sistema ferroviario transeuropeo convenzionale. Qualora l'osservanza di queste caratteristiche risulti difficile in determinate parti della rete, si potrebbero applicare soluzioni temporanee che garantiscano la compatibilità in futuro.» Questo requisito essenziale non si applica al sottosistema Applicazioni telematiche.

3.4.   Aspetti legati in modo specifico al sottosistema Applicazioni telematiche per il trasporto merci

3.4.1.   Compatibilità tecnica

—

Requisito essenziale 2.7.1 di cui all'allegato III della direttiva 2001/16/CE: «I requisiti essenziali nei campi delle applicazioni telematiche che garantiscono una qualità di servizio minimo ai viaggiatori e ai clienti del comparto merci concernono più particolarmente la compatibilità tecnica. Bisogna garantire per queste applicazioni che: — le basi di dati, il software e i protocolli di comunicazione dati siano sviluppati in modo da garantire un massimo di possibilità di scambio dati sia tra applicazioni diverse che tra operatori diversi, con le esclusioni dei dati commerciali di carattere riservato; — un accesso agevole dell'utenza alle informazioni.» La conformità a questo requisito essenziale è assicurata in modo specifico dai seguenti paragrafi: — 4.2.11: Principali dati di riferimento, — 4.2.12: Archivi di riferimento e banche dati varie, — 4.2.14: Reti e comunicazioni.

3.4.2.   Affidabilità e disponibilità

—

Requisito essenziale 2.7.2 di cui all'allegato III della direttiva 2001/16/CE: «I modi di uso, gestione, aggiornamento e manutenzione di queste basi di dati, software e protocolli di comunicazioni dati devono garantire l'efficacia di questi sistemi e la qualità del servizio.» La conformità a questo requisito è assicurata in modo specifico dai seguenti paragrafi: — 4.2.11: Principali dati di riferimento, — 4.2.12: Archivi di riferimento e banche dati varie, — 4.2.14: Reti e comunicazioni. Si noti inoltre che questo requisito essenziale, in particolare per quanto riguarda i modi di uso adottati per garantire l'efficacia delle applicazioni telematiche e la qualità del servizio, non è trattato solo nei paragrafi appena menzionati ma rappresenta il cardine di tutta la STI.

3.4.3.   Salute

—

Requisito essenziale 2.7.3 di cui all'allegato III della direttiva 2001/16/CE: «Le interfacce di questi sistemi con l'utenza devono rispettare le regole minime in materia di ergonomia e protezione della salute.» La presente STI non precisa requisiti ulteriori rispetto alle vigenti normative nazionali ed europee per quanto riguarda i criteri minimi di sicurezza in materia di ergonomia e protezione della salute che devono essere rispettati dall'interfaccia tra queste applicazioni telematiche e l'utenza.

3.4.4.   Sicurezza

—

Requisito essenziale 2.7.4 di cui all'allegato III della direttiva 2001/16/CE: «Devono essere garantiti sufficienti livelli d'integrità e attendibilità per la conservazione o la trasmissione d'informazioni inerenti alla sicurezza.» La conformità a questo requisito è assicurata dai seguenti paragrafi: — 4.2.11: Principali dati di riferimento, — 4.2.12: Archivi di riferimento e banche dati varie, — 4.2.14: Reti e comunicazioni.

4.   CARATTERISTICHE DEL SOTTOSISTEMA

4.1.   Introduzione

Il sistema ferroviario transeuropeo convenzionale, a cui si applica la direttiva 2001/16/CE e di cui fa parte il sottosistema Applicazioni telematiche, è un sistema integrato di cui occorre accertare la coerenza, in particolare per quanto riguarda le specifiche del sottosistema, le interfacce di quest'ultimo verso il sistema in cui è integrato, nonché le prescrizioni in materia di funzionamento e manutenzione.

Tenendo conto di tutti i requisiti essenziali applicabili, il sottosistema Applicazioni telematiche per il trasporto merci si definisce in base alle caratteristiche indicate di seguito.

4.2.   Specifiche funzionali e tecniche del sottosistema

Alla luce dei requisiti essenziali indicati nel capitolo 3 (Requisiti essenziali), le specifiche funzionali e tecniche del sottosistema riguardano i seguenti elementi:

—	dati delle lettere di vettura,

—	richieste di tracce orarie,

—	preparazione dei treni,

—	previsioni di marcia dei treni,

—	informazioni concernenti le perturbazioni del servizio,

—	posizione dei treni,

—	ETI/ETA dei carri/unità intermodali,

—	movimenti dei carri,

—	comunicazioni di interscambio,

—	scambio di dati a fini di miglioramento della qualità,

—	principali dati di riferimento,

—	archivi di riferimento e banche dati varie,

—	trasmissione elettronica dei documenti,

—	reti e comunicazioni.

Le specifiche dettagliate sono riportate di seguito. Per ulteriori informazioni e indicazioni sul formato dei messaggi si rimanda al documento 1 di cui all'allegato A.

Note generali sulla struttura dei messaggi

Ogni messaggio è composto da due insiemi di dati:

—	dati di controllo: descritti di seguito

—	dati informativi: informazioni dell'applicazione.

I dati di controllo indicano i seguenti elementi.

—	Status: lo status di un messaggio può essere: — «Nuovo messaggio», se si tratta di un nuovo messaggio. — «Variazione», se si tratta della modifica di un messaggio inviato in precedenza. — «Cancellazione» se si annulla un messaggio inviato in precedenza.

—	Riferimenti del messaggio, con le seguenti indicazioni: — Tipo di messaggio: ad es. «Richiesta di traccia oraria» o «Richiesta di informazioni sulla marcia del treno». — Data e ora: data e ora di invio del messaggio. — Numero del messaggio: numero assegnato dal mittente del messaggio.

—

Riferimenti del messaggio correlato, solo se il messaggio è inviato in risposta a un messaggio ricevuto in precedenza (e perciò identici ai riferimenti del messaggio ricevuto), con le seguenti indicazioni: — Tipo di messaggio correlato: tipo di messaggio ricevuto. — Data e ora del messaggio correlato: data e ora del messaggio ricevuto. — Numero del messaggio correlato: numero del messaggio ricevuto.

—	Mittente del messaggio

—	Destinatario del messaggio.

Nei paragrafi seguenti si prende in considerazione perlopiù lo status «Nuovo messaggio». Nel paragrafo 4.2.2, si fa riferimento anche allo status «Cancellazione» in relazione al messaggio Richiesta di traccia oraria.

4.2.1.   Dati della lettera di vettura

4.2.1.1.   Lettera di vettura del cliente

La lettera di vettura, inviata dal cliente all'IF responsabile, deve contenere tutte le informazioni necessarie per il trasporto del carico dal mittente al destinatario. L'IFR deve completare le informazioni fornite dal cliente con ulteriori dati. Le informazioni di partenza e i dati aggiunti dall'IFR sono indicati nel documento 3 di cui all'allegato A (a cui si rimanda anche per la descrizione del contenuto); nella riga «Dati della lettera di vettura» si precisa se si tratta di dati obbligatori o facoltativi e se devono essere forniti dal mittente o aggiunti dall'IFR.

Nella modalità di accesso libero, una volta inseriti i dati aggiuntivi l'IF responsabile che stipula il contratto con il cliente dispone di tutte le informazioni necessarie e non ha bisogno di avviare uno scambio di messaggi con altre IF. Questi dati servono anche per le richieste di tracce in gestione operativa, nei casi in cui queste sono necessarie per dare esecuzione alle lettere di vettura.

I messaggi indicati di seguito sono utilizzati in caso di coordinamento. Il contenuto dei messaggi può servire anche per le richieste di tracce in gestione operativa, nei casi in cui queste sono necessarie per dare esecuzione alle lettere di vettura.

4.2.1.2.   Richieste di carri

La richiesta di carri è essenzialmente un sottoinsieme delle informazioni contenute nella lettera di vettura. Deve essere inoltrata alle IF che intervengono nella catena di trasporto, in quanto può servire per la presentazione di una richiesta di traccia oraria ad hoc (paragrafo 4.2.2: Richiesta di traccia oraria). La richiesta deve contenere le informazioni di cui ha bisogno un'IF per eseguire il trasporto nel tratto di sua competenza fino al trasferimento all'IF successiva. Il contenuto, quindi, dipende dalla funzione dell'impresa ferroviaria: IF di origine, di transito, di destinazione (rispettivamente IFO, IFT, IFD).

—	Richiesta di carri per l'impresa ferroviaria di origine (IFO).

—	Richiesta di carri per l'impresa ferroviaria di transito (IFT).

—	Richiesta di carri per l'impresa ferroviaria di destinazione (IFD).

I dati da inserire nella richiesta di carri a seconda della funzione svolta dall'IF sono indicati in maniera particolareggiata nel documento 3 di cui all'allegato A, in cui è precisata anche la natura obbligatoria o facoltativa di ciascuno di essi. Il formato dettagliato dei messaggi è definito nel documento 1 di cui all'allegato A.

I dati principali delle richieste di carri sono i seguenti:

—	informazioni sul mittente e sul destinatario,

—	informazioni sull'istradamento,

—	dati identificativi del carico di merce,

—	dati sul carro,

—	luogo e data.

Alcuni dati della lettera di vettura devono essere accessibili a tutti i soggetti (ad es. GI, titolare, ecc.) che intervengono nella catena di trasporto, compresi i clienti. Con specifico riferimento ai singoli carri, questi dati sono:

—	peso del carico (peso lordo del carico),

—	numero CN/HS,

—	informazioni sulle merci pericolose,

—	unità di trasporto.

4.2.2.   Richiesta di traccia oraria

4.2.2.1.   Note preliminari

Pianificazione a lungo termine

La traccia oraria definisce i dati richiesti, accettati ed effettivi da conservare sulla traccia di un treno e le caratteristiche del treno in relazione a ciascun segmento della traccia. Di seguito sono indicate le informazioni che devono essere a disposizione del gestore dell'infrastruttura. Per una descrizione più dettagliata si rimanda al documento 4 di cui all'allegato A.

Le informazioni devono essere aggiornate ogniqualvolta interviene un cambiamento.

I dati principali della traccia oraria sono i seguenti.

—

Identificativo della traccia (numero di traccia). A seconda dei processi utilizzati dal GI, una traccia oraria può corrispondere ad un utilizzo pianificato di capacità lungo una sezione di itinerario, oppure all'istradamento effettivo di un treno lungo una determinata linea nell'ambito di un itinerario.

—	Punto di partenza della traccia. Indica il luogo di origine della traccia nonché la data e l'orario di partenza del treno sulla traccia.

—	Destinazione della traccia. Indica il luogo di destino della traccia nonché la data e l'orario previsti di arrivo a destino del treno.

—

Descrizione della sezione di percorso. Si tratta dei dati forniti dal GI per ogni sezione di percorso accettata — dall'inizio alla prima fermata intermedia, altre fermate intermedie e dall'ultima fermata intermedia al termine del percorso accettato. Nella descrizione possono essere precisati i seguenti elementi: — fermate intermedie o altri punti specificati lungo la traccia proposta, con l'indicazione della data e dell'orario di arrivo, partenza o transito in tali punti intermedi nonché di un codice attività, che definisce l'attività che deve essere effettuata in tale punto intermedio lungo l'itinerario, — dati identificativi del GI a cui compete la gestione del traffico per la sezione di percorso interessata e identificativo del GI a cui compete la gestione del traffico per la sezione di percorso successiva, — descrizione delle apparecchiature (sistema di comando e di controllo, sistema radio, ecc.) di cui deve essere equipaggiato il treno; tali apparecchiature devono essere compatibili con l'infrastruttura per consentire la trazione, il controllo e le comunicazioni dal treno al controllo del GI, — dati relativi al treno per la sezione di percorso: peso massimo, lunghezza massima, velocità massima, peso assiale massimo, sforzo di frenatura minimo, peso massimo al metro, informazioni su sagome eccezionali, identificativi di merci pericolose non consentite, — numero di traccia, — allungamento di percorrenza per la sezione di itinerario tenendo conto di recuperi, problemi sulla traccia, ecc.

Esecuzione del contratto relativo alla traccia: prima di far circolare il treno, occorre aggiornare la sezione di percorso e completarla con l'inserimento dei dati effettivi. La modalità di esecuzione è indipendente dalla modalità di pianificazione.

Richiesta di traccia oraria in gestione operativa

A fronte di fatti non previsti nel corso della marcia di un treno o di esigenze di trasporto in tempi brevi, un'impresa ferroviaria deve avere la possibilità di ottenere una traccia oraria ad hoc sulla rete.

Nel primo caso, si devono avviare interventi immediati, posto che sia nota l'effettiva composizione del treno in base alla lista veicoli.

Nel secondo caso, l'impresa ferroviaria deve fornire al gestore dell'infrastruttura tutti i dati necessari in merito a percorsi e orari di marcia richiesti per il treno; inoltre, deve indicare le caratteristiche fisiche del treno, sempre che queste abbiano rilevanza per l'utilizzo dell'infrastruttura. Tali dati sono indicati perlopiù nella lettera di vettura, integrata dalle richieste di carri.

L'accordo sulla traccia oraria richiesta per far circolare un treno in gestione operativa si basa su un dialogo tra IF e GI. Al dialogo partecipano tutte le IF e i GI che devono attivarsi per far circolare il treno nella traccia desiderata; il processo di individuazione della traccia può comportare però diversi livelli di partecipazione. Conformemente all'articolo 13 della direttiva 2001/14/CE, si possono distinguere fondamentalmente due diversi scenari generali validi per il trasporto di merci sulle infrastrutture di più GI (cfr. anche documento 5, paragrafo 1.3, di cui all'allegato A).

—

Scenario A: l'IF interpella tutti i GI interessati, mettendosi in contatto con ciascuno di essi direttamente (caso A) oppure rivolgendosi allo sportello unico (caso B), per organizzare le tracce per il percorso completo. In questo caso l'IF provvede alla circolazione del treno per l'intero percorso a norma dell'articolo 13 della direttiva 2001/14/CE.

—	Scenario B: ciascuna IF coinvolta nel percorso di trasporto interpella il GI locale direttamente o attraverso lo sportello unico per chiedere una traccia per la sezione di percorso per la quale provvede alla circolazione del treno.

Nota: come già accennato nel capitolo 2 (Definizione del sottosistema/campo di applicazione), nella modalità di esecuzione il GI comunica sempre con l'IF che ha prenotato la traccia. Per questo l'appartenenza della traccia è importante per lo scambio di messaggi durante l'esercizio del treno.

In entrambi gli scenari, la procedura di prenotazione di una traccia in gestione operativa avviene secondo il dialogo tra IF e GI interessati descritto in appresso.

Nella tabella seguente sono indicati i messaggi usati nel dialogo per la richiesta di traccia oraria.

Tabella 1

Richiesta di traccia oraria

Messaggio	Spiegazione
Messaggi usati nel dialogo per la richiesta di traccia oraria
Richiesta di traccia oraria	Il messaggio deve essere inviato dall’IF al GI o ai GI interessati per trasmettere una richiesta di traccia oraria in gestione operativa.
Dettagli della traccia oraria	Il messaggio deve essere inviato dal o dai GI all’IF per confermare i dettagli della traccia in risposta alla Richiesta di traccia oraria dell’IF, eventualmente con valori modificati oppure, qualora il GI non sia in grado di confermare la traccia richiesta, con l’indicazione «Nessuna alternativa disponibile».
Traccia oraria confermata	Il messaggio deve essere inviato dall’IF al GI a titolo di accettazione del messaggio Dettagli della traccia oraria inviato dal GI in risposta alla richiesta iniziale dell’IF.
Dettagli della traccia oraria rifiutati	Il messaggio deve essere inviato dall’IF al GI nel caso in cui l’IF, per la presenza di valori modificati che la stessa non può accettare, rifiuti i dettagli della traccia inviati dal gestore in risposta alla richiesta iniziale.

Il dialogo si conclude con l'invio del messaggio Traccia oraria confermata da parte dell'IF, oppure con la cancellazione della richiesta di traccia (messaggio Richiesta di traccia oraria con status «Cancellazione», cfr. paragrafo 4.2: Specifiche funzionali e tecniche del sottosistema, Note generali sulla struttura dei messaggi). Se il GI riceve dall'IF un messaggio Dettagli della traccia oraria rifiutati, è tenuto a rispondere inviando un nuovo messaggio Dettagli della traccia oraria. Se il GI non è in grado di dar seguito alla richiesta di traccia indicando una nuova proposta nel messaggio Dettagli della traccia oraria, deve trasmettere il messaggio Dettagli della traccia oraria con l'indicazione Nessuna alternativa disponibile, che pone fine al dialogo con il GI.

L'IF deve sempre poter annullare una traccia, indipendentemente dal fatto che la traccia sia stata prenotata nel quadro della pianificazione a lungo termine oppure in gestione operativa. Per l'annullamento di una traccia prenotata si utilizza il messaggio seguente.

Tabella 2

Annullamento di traccia oraria da parte dell'IF

Messaggio	Spiegazione
Messaggio usato per l’annullamento da parte dell’IF di una traccia prenotata
Traccia oraria annullata	Avviso che l’IF invia al GI per annullare una traccia prenotata in precedenza o parte di essa.

In presenza di un accordo su una traccia oraria, l'IF che ha prenotato la traccia può fare assegnamento sulla sua disponibilità. Pertanto, il GI deve comunicare immediatamente all'IF se a causa di motivi contingenti (ad esempio un'interruzione sulla traccia) la traccia prenotata non è più disponibile. L'indisponibilità di una traccia oraria può intervenire in qualsiasi momento tra la contrattualizzazione e la partenza del treno. Contestualmente all'indicazione di indisponibilità della traccia o quanto prima, se è impossibilitato a farlo subito, il GI è tenuto a inviare una proposta alternativa. Con il messaggio Traccia oraria non disponibile ha inizio un dialogo, avviato dal GI, finalizzato alla conclusione di un accordo su una nuova traccia oraria.

Messaggi usati nel dialogo per la soppressione da parte del GI di una traccia oraria prenotata.

Tabella 3

Soppressione di traccia oraria da parte del GI

Messaggio	Spiegazione
Messaggi usati nel processo di soppressione di una traccia oraria avviato dal GI
Traccia oraria non disponibile	Avviso inviato dal GI all’IF per comunicare che la traccia prenotata non è disponibile.
Dettagli della traccia oraria	Il messaggio deve essere inviato dal o dai GI all’IF per proporre una traccia alternativa dopo l’invio dell’avviso di indisponibilità della traccia prenotata.
Traccia oraria confermata	Il messaggio deve essere inviato dall’IF al GI a titolo di accettazione della traccia proposta nel messaggio Traccia oraria non disponibile.
Dettagli della traccia oraria rifiutati	Il messaggio deve essere inviato dall’IF al GI nel caso in cui l’IF non accetti la proposta inviata dal GI nel messaggio Traccia oraria non disponibile. In questo caso il GI deve inviare una nuova proposta. Il dialogo si conclude quando l’IF invia il messaggio Traccia oraria annullata in relazione a un messaggio Traccia oraria non disponibile del GI.

Di regola, se il destinatario di una richiesta o di un'interrogazione non è in grado di rispondere in tempo reale (ad esempio se il GI non può inviare immediatamente un messaggio Dettagli della traccia oraria in risposta a una Richiesta di traccia oraria), deve darne comunicazione al mittente del messaggio. A tal fine, si utilizza il seguente messaggio.

Tabella 4

Conferma di ricevimento

Messaggio	Spiegazione
Questo messaggio ha validità generale
Conferma di ricevimento	Il messaggio deve essere inviato dal destinatario di un messaggio al mittente dello stesso, quando la risposta richiesta non possa essere messa a disposizione entro il lasso di tempo indicato al paragrafo 4.4 (Norme operative, Tempestività).

Gli elementi principali di questi messaggi sono descritti nei paragrafi che seguono. Indicazioni dettagliate sul formato sono contenute nel documento 1 di cui all'allegato A. La sequenza logica è illustrata nei diagrammi contenuti nei paragrafi da 2.1 a 2.3 del documento 5 di cui all'allegato A.

4.2.2.2.   Messaggio Richiesta di traccia oraria

Si tratta del messaggio che l'IF trasmette al GI per chiedere una traccia oraria. La richiesta deve contenere i seguenti elementi:

—	punto di partenza della traccia: punto in cui ha origine la traccia proposta,

—	data/orario di partenza della traccia: data/orario per i quali viene richiesta la traccia proposta,

—	punto di destinazione della traccia: destinazione del treno per la traccia richiesta,

—	data/orario di arrivo a destinazione della traccia: data/orario previsti di arrivo a destinazione del treno proposto,

—

sezione di percorso richiesta: — fermate intermedie o altri punti specificati lungo la traccia proposta, con l'indicazione della data e dell'orario previsti di arrivo e partenza da ciascun punto intermedio. L'assenza di indicazioni a questo riguardo significa che il treno non si fermerà nel punto corrispondente, — equipaggiamento disponibile sul treno: tipo di trazione, sistema di comando e di controllo, comprese le apparecchiature radio a bordo, — peso del treno, — lunghezza del treno, — sistema di frenatura da utilizzare e prestazioni di frenatura, — velocità massima del treno, — peso assiale massimo del treno, — peso massimo al metro, — informazioni su sagome eccezionali, — numeri ONU/RID relativi alle eventuali merci pericolose, — definizioni delle attività da effettuare in ogni punto intermedio lungo l'itinerario, — IF competente: dati identificativi dell'IF sotto la cui responsabilità è posto il treno per la sezione di percorso considerata, — GI responsabile: dati identificativi del GI sotto la cui responsabilità è posto il treno per la sezione di percorso considerata, — GI responsabile successivo: dati identificativi del GI sotto la cui responsabilità è posto il treno per la sezione di percorso successiva (se prevista).

Per completare le informazioni necessarie per la formulazione della richiesta di traccia oraria, l'IF può consultare il prospetto informativo della rete per verificare se i dati del treno previsto sono compatibili con l'infrastruttura. Ai fini della richiesta è necessario tenere conto anche di dati quali le informazioni sulle merci pericolose.

I titolari dei carri devono rendere accessibili alle IF i dati tecnici sui carri.

Le IF, a loro volta, devono rendere accessibili gli archivi di riferimento, ad esempio l'archivio di riferimento sulle merci pericolose, nei casi in cui ciò sia richiesto.

4.2.2.3.   Messaggio Dettagli della traccia oraria

Si tratta del messaggio utilizzato dal GI per rispondere a un messaggio Richiesta di traccia oraria trasmesso da un'IF. Nel caso in cui il GI non possa confermare la traccia oraria richiesta, insieme a questo messaggio deve inviare l'indicazione Nessuna alternativa disponibile. Diversamente, deve rispondere alla richiesta dell'IF trasmettendo un numero di traccia con gli stessi dati contenuti nella richiesta di traccia oraria, eventualmente con valori modificati.

Per l'alternativa proposta dal GI devono essere inviati i seguenti dati:

—	nuovo numero di traccia,

—	punto di partenza della traccia: luogo in cui ha origine la traccia proposta,

—	data/orario di partenza della traccia: data/orario per i quali viene proposta la traccia,

—	punto di destinazione della traccia: destinazione del treno per la traccia proposta,

—	data/orario di arrivo a destinazione della traccia: data/orario in cui è previsto l'arrivo a destinazione del treno,

—

sezione di percorso modificata: — fermate intermedie o altri punti designati lungo la traccia proposta, con l'indicazione della data e dell'orario previsti di arrivo e partenza da ciascun punto intermedio. L'assenza di queste indicazioni significa che il treno non si fermerà nel punto corrispondente, — equipaggiamento richiesto sul treno: tipo di trazione, sistema di comando e di controllo, comprese le apparecchiature radio a bordo, — peso del treno, — lunghezza del treno, — sistema di frenatura da utilizzare e prestazioni di frenatura, — velocità massima del treno, — peso assiale massimo del treno, — peso massimo al metro, — informazioni su sagome eccezionali, — numeri ONU/RID relativi alle eventuali merci pericolose, — definizioni delle attività da effettuare in ogni punto intermedio lungo l'itinerario, — IF competente: dati identificativi dell'IF sotto la cui responsabilità è posto il treno per la sezione di percorso considerata, — GI responsabile: dati identificativi del GI sotto la cui responsabilità è posto il treno per la sezione di percorso considerata, — GI responsabile successivo: dati identificativi del GI sotto la cui responsabilità è posto il treno per la sezione di percorso successiva (se prevista).

4.2.2.4.   Messaggio Traccia oraria confermata

Si tratta del messaggio inviato dall'IF al GI a titolo di accettazione di una traccia proposta in risposta alla richiesta iniziale dell'IF. Con questo messaggio si effettua la prenotazione la traccia oraria. I dati principali del messaggio sono i seguenti:

—	numero della traccia: identifica la traccia a cui si riferisce il messaggio,

—	punto di partenza della traccia: punto da cui partirà il treno,

—	data/orario di partenza della traccia: data/orario per i quali viene richiesta la traccia,

—	punto di destinazione della traccia: destinazione del treno per la traccia richiesta,

—	data/orario di arrivo a destinazione della traccia: data/orario previsti di arrivo a destinazione del treno proposto,

—	indicazione dell'accettazione, da parte dell'IF, della traccia oraria proposta.

4.2.2.5.   Messaggio Dettagli della traccia oraria rifiutati

Si tratta del messaggio che l'IF invia al GI per informarlo del rifiuto della traccia oraria proposta nel messaggio Dettagli della traccia oraria. I dati principali del messaggio sono i seguenti:

—	numero della traccia: identifica la traccia a cui si riferisce il messaggio,

—	indicazione del rifiuto dei dettagli della traccia oraria.

A titolo complementare possono essere inviati anche i seguenti dati:

—	punto di partenza della traccia: punto da cui partirà il treno,

—	data/orario di partenza della traccia: data/orario per i quali viene richiesta la traccia,

—	punto di destinazione della traccia: destinazione del treno per la traccia richiesta,

—	data/orario di arrivo a destinazione della traccia: data/orario previsti di arrivo a destinazione del treno proposto.

4.2.2.6.   Messaggio Traccia oraria annullata

Si tratta del messaggio con cui l'IF comunica l'annullamento di una traccia oraria prenotata in precedenza. Insieme all'indicatore di cancellazione (che corrisponde al tipo di messaggio), deve essere specificato il numero della traccia in modo da identificare la traccia in modo univoco. Il messaggio può riferirsi a una traccia prenotata nella modalità di pianificazione oppure in gestione operativa:

—	numero della traccia: identifica la traccia a cui si riferisce il messaggio,

—	numero del treno (se già noto al GI),

—	indicatore di cancellazione: segnala l'annullamento della traccia oraria prenotata.

A titolo complementare possono essere inviati anche i seguenti dati:

—	punto di partenza della traccia: punto da cui partirà il treno,

—	data/orario di partenza della traccia: data/orario per i quali è stata richiesta la traccia,

—	punto di destinazione della traccia: destinazione del treno per la traccia richiesta,

—	data/orario di arrivo a destinazione della traccia: data/orario previsti di arrivo a destinazione del treno proposto.

4.2.2.7.   Messaggio Traccia oraria non disponibile

Il GI deve comunicare immediatamente all'IF la sopravvenuta indisponibilità di una traccia. Il messaggio Traccia oraria non disponibile può essere trasmesso in qualsiasi momento tra la contrattualizzazione della traccia e la partenza del treno. L'indisponibilità può essere dovuta ad esempio a un'interruzione sulla traccia. I dati principali del messaggio sono i seguenti:

—	numero della traccia non più disponibile,

—	numero del treno previsto per la traccia soppressa (se già noto al GI),

—	punto di partenza della traccia con la data e l'orario per i quali la traccia era prenotata,

—	punto di destinazione della traccia con la data e l'orario per i quali era previsto l'arrivo a destinazione del treno,

—	indicazione Traccia oraria non disponibile,

—	indicazione del motivo.

Contestualmente a questo messaggio o quanto prima, il GI deve inviare una proposta alternativa, senza bisogno di un'ulteriore richiesta da parte dell'IF. A tal fine, il GI utilizza il messaggio Dettagli della traccia oraria correlato al messaggio Traccia oraria non disponibile.

4.2.2.8.   Messaggio Conferma di ricevimento

Si tratta del messaggio che il destinatario di un messaggio deve inviare al mittente dello stesso nel caso in cui la risposta richiesta non possa essere resa disponibile entro il lasso di tempo indicato al paragrafo 4.4 (Norme operative). Il messaggio deve contenere i dati identificativi del messaggio a cui si riferisce (dati del messaggio correlato, cfr. paragrafo 4.2: Specifiche funzionali e tecniche del sottosistema, Note generali sulla struttura del messaggio) e l'indicazione (livello Applicazione):

—	Conferma del messaggio: indica che il destinatario ha ricevuto il messaggio e che si attiverà per darvi seguito.

4.2.3.   Preparazione del treno

4.2.3.1.   Note generali

Nei paragrafi seguenti sono precisati i messaggi che GI e IF si devono scambiare durante la preparazione del treno fino al momento della partenza. I messaggi sono indicati più avanti, nella tabella 5.

Per la preparazione del treno, l'IF deve avere accesso agli avvisi di restrizione dell'infrastruttura, ai dati tecnici dei carri (paragrafo 4.2.11.3: Banche dati di riferimento sul materiale rotabile), all'archivio di riferimento delle merci pericolose e allo stato corrente aggiornato delle informazioni concernenti i carri (paragrafo 4.2.12.2: Altre banche dati: Banca dati operativa dei carri e delle unità intermodali) per tutti i carri in composizione al treno. Al termine del processo, l'IF deve trasmettere la composizione del treno alle IF successive. Lo stesso messaggio deve essere inviato anche al o ai GI presso i quali l'IF ha prenotato una sezione di traccia oraria, se lo richiedono la STI Esercizio e gestione del traffico per il sistema ferroviario convenzionale o i contratti tra IF e GI.

Se, in una certa località, la composizione del treno viene modificata, l'IF responsabile deve inviare nuovamente il messaggio, aggiornandone i dati.

Il dialogo tra GI e IF relativo alla procedura di partenza (Treno pronto –Avviso di treno in marcia) riveste carattere di obbligatorietà in ogni punto in cui si attua un passaggio di responsabilità tra IF, ad esempio nei punti di origine e interscambio.

I messaggi utilizzati nel dialogo relativo alla procedura di partenza sono i seguenti.

Tabella 5

Preparazione del treno

Messaggio		Spiegazione
Composizione del treno		Questo messaggio deve essere inviato dall’IF al GI secondo quanto descritto in precedenza.
	In risposta al messaggio obbligatorio Composizione del treno dell’IF, il GI può inviare uno dei seguenti messaggi:
	Treno accettato	Questo messaggio facoltativo può essere inviato dal GI all’IF, se non diversamente concordato tra GI e IF.	La preparazione del treno può essere completata.
	Treno non compatibile	Questo messaggio può essere inviato dal GI all’IF, qualora il GI accerti questa condizione.	L’IF può:   modificare la composizione del treno, oppure   inviare un messaggio di annullamento della traccia oraria e richiederne una nuova.
Treno pronto		Questo messaggio deve essere inviato dall’IF al GI.
Posizione del treno		Questo messaggio, inviato dal GI all’IF, definisce esattamente luogo e orario di accesso alla rete. La trasmissione di questo messaggio dipende dalle norme nazionali.
Treno in partenza		Questo messaggio può essere inviato dall’IF al GI, una volta ricevuto il messaggio Posizione del treno, al fine di indicare che il treno ha iniziato il percorso. La trasmissione di questo messaggio dipende dalle norme nazionali.
Avviso di treno in marcia		Questo messaggio deve essere inviato dal GI all’IF per indicare che il treno si è immesso sull’infrastruttura.

Gli elementi principali di questi messaggi sono descritti nei paragrafi che seguono. Indicazioni dettagliate sul formato sono contenute nel documento 1 di cui all'allegato A. La sequenza logica è illustrata nel documento 5, capitolo 3, di cui all'allegato A.

Nota: durante la preparazione di un treno è possibile che venga trasmesso anche un messaggio Traccia oraria non disponibile; questo messaggio, infatti, può essere inviato in qualsiasi momento tra la contrattualizzazione della traccia e la partenza del treno. La procedura da seguire in questo caso è descritta al paragrafo 4.2.2 (Richiesta di traccia oraria).

4.2.3.2.   Messaggio Composizione del treno

Si tratta del messaggio che l'IF invia all'IF successiva per indicare la composizione del treno; lo stesso messaggio è inviato dall'IF al o ai GI nel caso in cui la STI Esercizio e gestione del traffico per il sistema ferroviario convenzionale o il contratto tra GI e IF lo richiedano. Se la composizione del treno viene modificata durante la corsa del treno, l'IF responsabile deve inviare nuovamente il messaggio ai tutti i soggetti interessati, aggiornandone i dati.

Le informazioni che devono essere trasmesse e di cui deve essere garantita l'accessibilità sono le seguenti:

—	numero del treno e numero della traccia, per identificare la traccia a cui si riferisce il messaggio,

—	punto di partenza della traccia e data e orario per i quali è stata richiesta la traccia,

—	punto di destinazione della traccia e data e orario in cui è previsto l'arrivo a destinazione del treno,

—	identificativo della o delle locomotive e ubicazione della o delle locomotive nel treno,

—	lunghezza del treno, peso del treno, velocità massima del treno,

—	composizione del treno con la sequenza degli identificativi dei veicoli,

—	sistema di comando e di controllo, compreso il tipo di apparecchiatura radio,

—	informazioni su sagome eccezionali,

—	numeri ONU/RID delle merci pericolose,

—	indicazione dell'eventuale presenza di bestiame e persone (in aggiunta al personale viaggiante) sul treno,

—	sistema di frenatura da utilizzare,

—	dati dei carri.

Una volta ricevuta la composizione del treno, il GI può verificare le informazioni facendo riferimento alla traccia oraria contrattualizzata, se ciò è esplicitamente previsto dal contratto esistente tra il GI e l'IF. In tal caso, il GI deve poter accedere agevolmente alle informazioni sulle eventuali restrizioni dell'infrastruttura, ai dati tecnici dei carri (paragrafo 4.2.11.3:Banche dati di riferimento sul materiale rotabile), all'archivio di riferimento sulle merci pericolose e allo stato corrente aggiornato delle informazioni su tutti i carri che compongono il treno (paragrafo 4.2.12.2: Altre banche dati, Banca dati operativa dei carri e delle unità intermodali). Anche in questo caso, il GI, che gestisce le tracce orarie e aggiorna lo stato delle informazioni relative alle tracce, deve aggiungere i dettagli della composizione del treno ai dati relativi alla traccia oraria e al treno, così come indicato al paragrafo 4.2.2.1 (Richiesta di traccia oraria, Note preliminari).

4.2.3.3.   Messaggio Treno accettato

Si tratta del messaggio che il GI può utilizzare, se lo richiedono gli accordi contrattuali tra GI e IF e le disposizioni normative vigenti, per avvisare l'IF di avere accettato la composizione del treno per la traccia richiesta.

I dati principali del messaggio sono i seguenti:

—	numero del treno e della traccia,

—	punto di partenza della traccia, data e orario per i quali è stata richiesta la traccia,

—	punto di destinazione della traccia, data e orario per i quali è previsto l'arrivo a destinazione del treno,

—	indicazione con cui il GI informa l'IF di avere accettato la composizione del treno ritenendola compatibile con la traccia concordata.

4.2.3.4.   Messaggio Treno non compatibile

Si tratta del messaggio con cui il GI può informare l'IF che un treno non è compatibile con le caratteristiche della traccia precedentemente concordata. In questo caso, l'IF deve rivedere la composizione del treno. I dati principali del messaggio sono i seguenti:

—	numero del treno e della traccia,

—	punto di partenza della traccia con la data e l'orario per i quali è stata richiesta la traccia,

—	punto di destinazione della traccia con la data e l'orario previsti di arrivo a destinazione del treno,

—	indicazione Non compatibile, che segnala che il treno non è compatibile con le caratteristiche della traccia oraria assegnata e quindi non può circolare,

—	indicazione del motivo.

4.2.3.5.   Messaggio Treno pronto

Si tratta del messaggio che l'IF invia al GI per segnalare che il treno è pronto ad immettersi sulla rete. I dati principali del messaggio sono i seguenti:

—	numero del treno e della traccia,

—	punto di partenza della traccia con la data e l'orario per i quali è stata richiesta la traccia,

—	punto di destinazione della traccia con la data e l'orario previsti di arrivo a destinazione del treno proposto,

—	indicazione Treno pronto, che segnala che la preparazione del treno è stata completata e che il treno è pronto a circolare,

—	dati identificativi del referente per il controllo, per tutte le comunicazioni treno-terra,

—

se gli accordi contrattuali tra IF e GI non richiedono lo scambio dei messaggi Posizione del treno/Treno in partenza, in questo messaggio devono essere precisati la data e l'orario di inizio del percorso del treno, che indicano al GI la data/orario in cui è previsto che il treno si immetta sulla rete. Se è previsto l'invio dei messaggi Posizione del treno/Treno in partenza, queste informazioni non devono essere trasmesse.

4.2.3.6.   Messaggio Posizione del treno

Si tratta del messaggio che il GI può inviare all'IF in risposta al messaggio Treno pronto per definire esattamente luogo e orario di accesso alla rete. La trasmissione di questo messaggio dipende dagli accordi contrattuali stipulati tra IF e GI. Se in base a tali accordi la trasmissione è obbligatoria, i dati principali del messaggio sono i seguenti:

—	numero del treno e della traccia,

—	punto di partenza della traccia con la data e l'orario per i quali è richiesta la traccia,

—	punto di destinazione della traccia con la data e l'orario previsti di arrivo a destinazione del treno,

—	identificativo del binario, per informare l'IF del binario su cui deve presentarsi il treno per accedere alla rete,

—	data/orario di inizio della corsa del treno, per informare l'IF della data e dell'orario esatto di accesso alla rete,

—	dati identificativi del referente per il controllo.

4.2.3.7.   Messaggio Treno in partenza

Si tratta del messaggio che l'IF può inviare al GI, una volta ricevuto il messaggio Posizione del treno, al fine di indicare che il treno ha iniziato la corsa. Il messaggio deve essere accompagnato dal codice di identificazione del treno e deve contenere l'indicazione:

—	Treno in partenza: data/orario effettivi di inizio della corsa.

4.2.3.8.   Avviso di treno in marcia

Si tratta del messaggio che il GI invia all'IF che ha prenotato la traccia non appena il treno si è immesso sull'infrastruttura dello stesso GI. Il messaggio è descritto al paragrafo 4.2.4 (Previsione di marcia del treno).

4.2.4.   Previsione di marcia del treno

4.2.4.1.   Note generali

In questo paragrafo vengono precisati i messaggi che IF e GI si devono scambiare durante la marcia normale di un treno senza interruzioni.

I messaggi sono:

Previsione di marcia del treno,

Avviso di treno in marcia.

Lo scambio di informazioni tra IF e GI si attua sempre tra il GI competente e l'IF che ha prenotato la traccia su cui sta viaggiando il treno. In caso di accesso libero, ossia quando le tracce che formano il percorso completo sono prenotate da una sola IF (che perciò provvede a far viaggiare il treno per l'intero percorso), i messaggi sono inviati all'IF in questione. Lo stesso principio vale se la prenotazione delle tracce da parte dell'IF si effettua tramite l'OSS.

Per l'ulteriore trattazione si distinguono quattro scenari diversi, tenendo conto delle varie modalità di comunicazione tra IF e GI negli scenari di prenotazione delle tracce di cui al paragrafo 4.2.2.1 (Richiesta di traccia oraria, Note preliminari, scenari A e B):

—	Treno in avvicinamento a un punto di trasferimento tra il GI 1 e il vicino GI 2

Questo scenario prevede che il punto di trasferimento non sia anche un punto di interscambio (solo scenario B), né un punto di manipolazione. Il punto di trasferimento, quindi, corrisponde a un punto lungo le tracce prenotate da un'IF, e l'IF ha già inviato la composizione del treno al GI 2, contestualmente all'invio del messaggio al GI 1.

Dopo che il treno ha lasciato il punto di partenza (5), il GI 1 deve inviare al GI 2 un messaggio di Previsione di marcia del treno con l'orario previsto di trasferimento (ETH). Il messaggio è inviato contemporaneamente anche all'IF.

Quando il treno abbandona l'infrastruttura del GI 1 al punto di trasferimento, il GI 1 invia all'IF con cui ha stipulato il contratto per la traccia un Avviso di treno in marcia con l'indicazione dell'orario effettivo di trasferimento in detto punto.

Quando il treno si immette nell'infrastruttura del GI 2 al punto di trasferimento, il GI 2 invia all'IF con cui ha stipulato il contratto per la traccia un Avviso di treno in marcia con l'indicazione dell'orario effettivo di trasferimento in detto punto.

—	Treno in avvicinamento a un punto di interscambio tra l'IF 1 e la seguente IF 2 (solo scenario B)

Nel contratto relativo a una traccia, ogni punto di interscambio deve sempre essere considerato un punto di segnalazione. (I TETA ai punti di segnalazione sono calcolati dai GI conformemente a quanto precisato nei contratti con le IF.)

Per ogni punto di interscambio, una volta che il treno ha abbandonato il punto di segnalazione precedente, il GI competente invia all'IF con cui ha stipulato il contratto per la traccia oraria (ad es. IF 1) un messaggio Previsione di marcia del treno con l'indicazione del TETA. L'IF 1 inoltra il messaggio all'IF successiva (ad es. IF 2) della catena di trasporto, nonché all'IF responsabile (IFR) per il trasporto, ammesso che ve ne sia una e che il contratto di cooperazione tra le IF lo preveda.

Se il punto di interscambio è anche un punto di trasferimento, ad esempio tra il GI 1 e il GI 2, il GI 1 invia al GI 2 il messaggio Previsione di marcia del treno con l'indicazione dell'orario previsto di riferimento (ETH) già dopo che il treno ha lasciato il punto di partenza o di interscambio precedente. Il messaggio viene inviato anche all'IF che ha stipulato il contratto per la traccia, ad es. l'IF 1. Per l'IF, l'ETH equivale al TETA al punto di interscambio. L'IF 1 trasferisce il messaggio all'IF 2 sua vicina e all'IF responsabile per il trasporto, ammesso che ve ne sia una e che il contratto di cooperazione tra le IF lo preveda.

Quando il treno giunge a un punto di interscambio, il GI deve inviare all'IF con cui ha stipulato il contratto per la traccia, ad esempio l'IF 1, un Avviso di treno in marcia con l'indicazione dell'orario effettivo di arrivo in tale punto.

Prima che il treno abbandoni il punto di interscambio, l'IF 2 deve inviare al GI che ha assegnato la traccia un nuovo messaggio Composizione del treno e seguire la procedura per la partenza descritta al punto 4.2.3 (Preparazione del treno).

—	Treno in avvicinamento a un punto di manipolazione di un'IF (scenario A)

Nel contratto relativo alla traccia, ogni punto di manipolazione deve sempre essere considerato un punto di segnalazione.

Per tali punti, il GI competente deve inviare un messaggio Previsione di marcia del treno con l'indicazione del TETA solo se ciò è espressamente previsto nel contratto tra il GI e l'IF.

Se però il punto di manipolazione è anche un punto di trasferimento, ad esempio tra il GI 1 e il GI 2, dopo la partenza dal punto di partenza o di interscambio precedente il GI 1 deve inviare al GI 2 il messaggio Previsione di marcia del treno con l'indicazione dell'orario previsto di trasferimento (ETH). Lo stesso messaggio è inviato anche all'IF. Per l'IF l'ETH equivale al TETA al punto di manipolazione.

Quando il treno giunge al punto di manipolazione, il GI deve inviare all'IF un Avviso di treno in marcia con l'orario effettivo di arrivo in tale punto.

Prima che il treno abbandoni il punto di manipolazione, l'IF e il GI devono seguire la procedura per la partenza definita al paragrafo 4.2.3 (Preparazione del treno).

—	Treno giunto a destinazione

Quando il treno giunge a destinazione, il GI responsabile invia all'IF con cui ha stipulato il contratto per la traccia un messaggio Avviso di treno in marcia con l'orario effettivo di arrivo.

Nota: nel contratto relativo alla traccia possono essere definite anche altre località in corrispondenza delle quali devono essere inviati un messaggio di Previsione di marcia del treno completo di TETA e un messaggio di Avviso di treno in marcia con l'indicazione dell'orario effettivo. Per questi punti, il GI competente invia i messaggi precisati nel contratto. La valutazione e l'elaborazione successive degli orari effettivi rispetto all'ETH e al TETA sono descritte nei paragrafi da 4.2.7 (ETI/ETA della spedizione) a 4.2.9 (Comunicazioni di interscambio).

Nei paragrafi seguenti, vengono descritti i messaggi Previsione di marcia del treno e Avviso di treno in marcia facendo riferimento soltanto ai dati principali. Il formato dettagliato dei messaggi è precisato nel documento 1 di cui all'allegato A. La sequenza logica dello scambio di messaggi in relazione ai diversi scenari di comunicazione è illustrata nel documento 5, capitolo 4, di cui all'allegato A; a questo proposito, si osserva che, per quanto riguarda le modalità di comunicazione tra IF e GI per il treno in marcia, i due scenari di richiesta di traccia A(caso A) e A(caso B) (paragrafo 4.2.2.1: Richiesta di traccia oraria, Note preliminari) sono identici perché in entrambi i casi il GI conosce solo una IF, ad es. l'IF 1, che fa circolare il treno su tutta la traccia ed è anche responsabile della nuova composizione del treno ai punti di manipolazione.

4.2.4.2.   Messaggio Previsione di marcia del treno

Questo messaggio deve essere trasmesso dal GI per i punti di trasferimento, i punti di interscambio e la destinazione del treno, così come descritto al paragrafo 4.2.4.1 (Previsione di marcia del treno, Note generali).

Il messaggio, inoltre, deve essere trasmesso dal GI all'IF per gli altri punti di segnalazione indicati nei contratti tra IF e GI (ad es. per i punti di manipolazione).

I dati principali sono i seguenti:

—	numero della traccia e del treno,

—	data e orario programmati di partenza dalla località del GI (o orario programmato di trasferimento al GI successivo),

—	identificativo del punto di segnalazione,

—	data/orario previsti al punto di segnalazione.

4.2.4.3.   Messaggio Avviso di treno in marcia

Questo messaggio deve essere inviato nei seguenti casi:

—	alla partenza da ogni punto di partenza, all'arrivo a destinazione,

—

all'arrivo e alla partenza da ogni punto di trasferimento, punto di interscambio e in tutti i punti di segnalazione definiti nel contratto (ad es. i punti di manipolazione). I dati principali sono i seguenti: — numero della traccia e del treno, — data e orario programmati di partenza dalla località del GI, — identificativo del punto di segnalazione più recente, — orario effettivo al punto di segnalazione, — stato del treno al punto di segnalazione (arrivo, partenza, transito, non specificato, partenza dall'origine, arrivo a destinazione), — binario di arrivo alla località, — binario di partenza dalla località, — delta orario rispetto al prenotato programmato (minuti di differenza), — programma corrente, nell'ipotesi di più riprogrammazioni, — per ciascuna differenza rispetto all'orario prenotato programmato al punto di segnalazione: — codice del motivo (eventualmente più d'uno), — differenza, in termini di tempo, per il codice considerato (per ciascun punto di segnalazione possono essere indicati più motivi), — eventuale testo libero riguardante la differenza.

4.2.5.   Informazioni concernenti la perturbazione del servizio

4.2.5.1.   Note generali

Quando un'IF viene a conoscenza di una perturbazione del servizio durante la marcia di un treno di cui è responsabile, provvede ad informarne immediatamente il GI (nessun messaggio IT ad es. trasmesso a voce dal macchinista). Se necessario, l'IF aggiorna la banca dati operativa dei carri e delle unità intermodali. Se necessario, il GI aggiorna i dati sull'infrastruttura contenuti nella banca dati degli avvisi di restrizione dell'infrastruttura e/o i dati sulla traccia nella banca dati del treno.

Se il ritardo è superiore a x minuti (il valore è definito in sede contrattuale da IF e GI), il GI interessato deve inviare all'IF un messaggio Previsione di marcia del treno per il punto di segnalazione successivo.

Se il treno viene soppresso, il GI invia un messaggio di interruzione della marcia del treno, le cui caratteristiche sono descritte più avanti.

Se a causa di un imprevisto l'IF o il GI non è in grado di far viaggiare il treno all'orario previsto, deve essere negoziata una nuova traccia secondo la procedura descritta al punto 4.2.2 (Richiesta di traccia oraria).

4.2.5.2.   Messaggio di interruzione della marcia del treno

Si tratta del messaggio che il GI invia al GI successivo e all'IF con cui ha stipulato il contratto relativo alla traccia in caso di soppressione del treno.

I dati principali del messaggio sono i seguenti:

—	numero della traccia e del treno,

—	identificativo della località,

—	data e orario programmati di partenza da tale località,

—	motivo dell'interruzione,

—	descrizione dell'interruzione.

4.2.6.   Posizione del treno

4.2.6.1.   Introduzione

Nei paragrafi successivi sono precisate le informazioni che assicurano la rintracciabilità del treno, vale a dire la possibilità di ottenere informazioni sulla sua posizione. L'IF può chiedere al GI informazioni sui propri treni in qualsiasi momento. Le informazioni che l'IF può chiedere al GI sono le seguenti:

—	marcia del treno (ultima posizione rilevata, ritardi, motivi dei ritardi),

—	prestazioni del treno (ritardi, località e motivi dei ritardi),

—	tutti codici di identificazione di un determinato treno,

—	previsione del treno in una determinata località,

—	previsione di marcia di tutti i treni in una determinata località.

L'accesso a queste informazioni deve essere indipendente dalle comunicazioni tra IF e GI durante la marcia del treno. Ciò significa che l'IF deve disporre di un indirizzo di accesso unico (6) a tali informazioni. Le informazioni si basano principalmente sui dati registrati contenuti nei messaggi indicati in precedenza.

4.2.6.2.   Richiesta di informazioni sulla marcia del treno

Scopo	:	si tratta del messaggio usato dall'IF per chiedere informazioni circa l'ultimo stato registrato (località, ritardi e motivi dei ritardi) di un treno specifico in marcia sull'infrastruttura di un determinato GI.
Richiesta	:	dati principali — numero di identificazione del treno, — identificativo del GI, — data e orario programmati di partenza dalla località del GI.
Risposta	:	informazioni: — località di segnalazione più recente, — orario effettivo al punto di segnalazione, — stato del treno al punto di segnalazione (arrivo, partenza, transito, non specificato, partenza dall'origine, arrivo a destinazione), — binario di arrivo alla località, — orario di partenza dalla località, — orario prenotato programmato, — delta ritardo rispetto all'orario prenotato programmato, — orario riprogrammato (rispetto al programma corrente nell'ipotesi di più riprogrammazioni), — per ciascun ritardo in tale località di segnalazione: — codice del motivo e entità del ritardo per tale codice.

4.2.6.3.   Richiesta di informazioni sui ritardi/prestazioni del treno

Scopo	:	si tratta del messaggio usato dell'IF per chiedere informazioni su tutti i ritardi di un treno specifico sull'infrastruttura di un particolare GI.
Richiesta	:	dati principali — numero di identificazione del treno, — identificativo del GI, — data e orario programmati di partenza dalla località del GI.
Risposta	:	informazioni (uguali a quelle della Richiesta di informazioni sulla marcia del treno, non solo per il punto più recente ma per ciascun punto di segnalazione del treno sull'infrastruttura del GI specificato): — per ciascun punto di segnalazione: — località di segnalazione più recente, — orario effettivo al punto di segnalazione, — stato del treno al punto di segnalazione (arrivo, partenza, transito, non specificato, partenza dall'origine, arrivo a destinazione), — binario di arrivo alla località, — binario di partenza dalla località, — orario prenotato programmato, — delta ritardo sull'orario prenotato programmato, — orario riprogrammato (rispetto al programma corrente, nell'ipotesi di più riprogrammazioni), — per ciascun ritardo in tale località di segnalazione: — codice del motivo e entità del ritardo per tale codice.

4.2.6.4.   Richiesta di informazioni sul codice di identificazione del treno

Scopo	:	si tratta del messaggio usato dall'IF per chiedere informazioni sul codice di identificazione corrente di un treno e sui codici di identificazione precedenti. Per la richiesta può essere utilizzato uno qualsiasi dei codici di identificazione utilizzati per il treno specifico.
Richiesta	:	dati principali — numero di identificazione noto del treno, — identificativo del GI, — data e orario programmati di partenza dalla località del GI.
Risposta	:	informazioni: — codice di identificazione corrente del treno: — numero di identificazione del treno, — data e orario programmati di partenza dalla località del GI, — per ogni altro codice di identificazione del treno: — numero di identificazione del treno, — data e orario programmati di partenza dalla località del GI.

4.2.6.5.   Richiesta di informazioni al GI circa la previsione di marcia del treno

Scopo	:	si tratta del messaggio usato dall'IF per chiedere informazioni sull'orario previsto di un treno in corrispondenza di una determinata località di segnalazione oppure, in mancanza di indicazioni circa la località di segnalazione, in corrispondenza del punto di trasferimento dal GI.
Richiesta	:	dati principali — numero di identificazione del treno, — data e orario programmati di partenza dalla località del GI, — codice di identificazione della località di segnalazione (località di segnalazione per la quale è richiesta la previsione. Questo dato è facoltativo; se non viene indicato, la risposta si riferisce al punto di segnalazione finale del GI specifico per il treno in questione).
Risposta	:	informazioni: — codice del GI, — codice di identificazione del punto di segnalazione, — data/orario previsti al punto di segnalazione.

4.2.6.6.   Richiesta di informazioni al GI sui treni in corrispondenza della località di comunicazione

Scopo	:	si tratta del messaggio usato dall'IF per chiedere informazioni riguardo a tutti propri treni in corrispondenza di una particolare località di segnalazione nell'infrastruttura di un determinato GI.
Richiesta	:	dati principali — codice del GI, — codice di identificazione della località di segnalazione (località di segnalazione per la quale è richiesta la previsione. Questo dato è facoltativo; se non viene indicato, la risposta si riferisce al punto di segnalazione finale del GI specifico per il treno specifico).
Risposta	:	informazioni: — per ciascun treno dell'IF richiedente: — numero di identificazione del treno, — data e orario programmati di partenza dalla località del GI o orario programmato di trasferimento, — codice del GI, — identificazione del punto di segnalazione, — data/orario previsti al punto di segnalazione.

4.2.7.   ETI/ETA della spedizione

4.2.7.1.   Nota preliminare

Nei paragrafi da 4.2.2 (Richiesta di traccia oraria) a 4.2.6 (Posizione del treno) sono descritte le comunicazioni tra l'IF e il GI. Dato che al gestore dell'infrastruttura competono il monitoraggio e il controllo dei treni, l'elemento principale ai fini di queste comunicazioni è il numero di treno. Le informazioni sui carri contenute nel messaggio sulla composizione del treno hanno rilevanza ai fini della verifica della composizione del treno rispetto al contratto stipulato tra GI e IF per la traccia, nonché in caso di imprevisti.

Il monitoraggio di singoli carri o unità intermodali non rientra in questo scambio di informazioni; viene effettuato a livello di IF/IFR sulla base dei messaggi relativi ai treni ed è descritto di seguito nei paragrafi da 4.2.7 (ETI/ETA della spedizione) a 4.2.9 (Comunicazioni di interscambio).

Lo scambio di informazioni sui carri o sulle unità intermodali e il loro aggiornamento avvengono essenzialmente attraverso i «piani di inoltro» e i «movimenti dei carri» (paragrafo 4.2.12.2: Altre banche dati).

Come già accennato al paragrafo 2.3.2 (Processi presi in considerazione), per un cliente l'informazione più importante è sempre l'orario previsto di arrivo (ETA) della spedizione. L'ETA relativa al carro e l'ETI sono le informazioni fondamentali anche nelle comunicazioni tra IFR e IF. Sono lo strumento principale a disposizione dell'IFR per monitorare il trasporto fisico di una spedizione e per verificare il rispetto degli impegni assunti nei confronti del cliente.

Gli orari previsti indicati nei messaggi relativi ai treni si riferiscono tutti all'arrivo del treno in un determinato punto, che può essere un punto di trasferimento, un punto di interscambio, la destinazione del treno o un altro punto di segnalazione. Tutti questi orari corrispondono ad orari previsti di arrivo del treno (TETA). Un TETA può avere significati diversi per i vari carri o unità intermodali che compongono il treno. Ad esempio, per alcuni carri o unità intermodali il TETA relativo a un punto di interscambio può essere l'orario previsto di interscambio (ETI). Per altri carri che rimangono agganciati al treno per proseguire il trasporto con la stessa IF, il medesimo TETA può non avere alcuna rilevanza. Spetta all'IF che riceve informazioni sul TETA identificare ed elaborare tali informazioni, inserirle come informazioni sui movimenti di un carro nella banca dati operativa dei carri e delle unità intermodali e comunicarle all'IFR, se il treno non circola in modalità di accesso libero. Questi aspetti sono trattati nei paragrafi seguenti.

4.2.7.2.   Calcolo dell'ETI/ETA

Il calcolo dell'ETI/ETA si basa sulle informazioni ricevute dal GI competente, il quale invia, nel messaggio Previsione di marcia del treno, l'orario previsto di arrivo del treno (TETA) per determinati punti di segnalazione (e comunque per i punti di trasferimento, interscambio o arrivo, compresi i terminali intermodali) presenti nella traccia oraria concordata, ad es. per il punto di trasferimento da un GI al successivo (in questo caso, il TETA equivale all'ETH).

Per i punti di interscambio o per altri punti di segnalazione precisati della traccia oraria concordata, l'IF deve calcolare per l'IF successiva della catena di trasporto l'orario previsto di interscambio (ETI) per i carri e/o le unità intermodali.

Poiché un'IF può avere in uno stesso treno più carri impegnati in percorsi diversi e con IFR diverse, il punto di interscambio per il calcolo dell'ETI può essere diverso per i vari carri, come spiegano i due esempi semplificati riportati di seguito (per la rappresentazione grafica di questi due scenari si rimanda al documento 5, paragrafo 1.4, di cui all'allegato A; il diagramma della sequenza relativa all'esempio 1 per il punto di interscambio C è illustrato nel documento 5, paragrafo 5, di cui all'allegato A).

Esempio 1	:	l'IF1 ha in uno stesso treno i carri 1 e 2 posti sotto il coordinamento dell'IFR1 e i carri 3, 4 e 5 posti sotto il coordinamento dell'IFR2. Al punto di interscambio C, il trasporto dei carri 1 e 2 prosegue con l'IF2, mentre quello dei carri 3, 4 e 5 prosegue con l'IF3. In questo caso l'IF1 deve calcolare, per il punto di interscambio C, l'ETI per i carri 1 e 2 e inviare i valori risultanti all'IFR1. Per lo stesso punto di interscambio C, l'IF1 deve calcolare anche l'ETI per i carri 3, 4 e 5 e inviare i valori risultanti all'IFR2.
Esempio 2	:	l'IF1 ha in uno stesso treno i carri 1 e 2 posti sotto il coordinamento dell'IFR1 e i carri 3, 4 e 5 posti sotto il coordinamento dell'IFR2. Al punto di interscambio C, il trasporto dei carri 3, 4 e 5 prosegue con l'IF3 mentre quello dei carri 1 e 2 prosegue con il treno dell'IF1 fino al punto di interscambio E, dove la responsabilità dei carri viene trasferita all'IF2. In questo caso, per il punto di interscambio C l'IF1 deve calcolare soltanto l'ETI per i carri 3, 4 e 5 e inviare i valori risultanti all'IFR2. Per i carri 1 e 2 il punto di interscambio C non ha alcuna rilevanza. Il punto di interscambio successivo avente rilevanza per tali carri è il punto E; per tale punto, l'IF1 deve calcolare l'ETI e inviare i valori risultanti all'IFR1.

Sulla base dell'ETI comunicato dall'IF precedente, l'IF successiva calcola l'ETI relativo al carro per il punto di interscambio successivo. Questa procedura viene applicata ogni volta che un'IF subentra a un'altra IF. Quando l'ultima IF (IF n) della catena di trasporto del carro riceve l'ETI dall'IF precedente (IF n-1) per l'interscambio del carro tra IF n-1 e IF n, l'ultima IF (IF n) deve calcolare l'orario previsto di arrivo alla destinazione finale, allo scopo di organizzare la dislocazione dei carri in base alle richieste di carri e agli impegni assunti dall'IFR nei confronti del cliente. Questo orario è l'ETA relativo al carro; deve essere inviato all'IFR e conservato in forma elettronica insieme ai dati sui movimenti del carro. L'IFR deve mettere il cliente in condizione di accedere ai dati di sua pertinenza, conformemente a quanto stabilito nel contratto.

Nota sulle unità intermodali: se un carro trasporta unità intermodali, gli ETI del carro corrispondono a quelli delle unità intermodali. Riguardo agli ETA relativi alle unità intermodali, è bene notare che l'IF non è in grado di calcolare tale orario per la parte di trasporto che avviene successivamente a quella effettuata a mezzo ferrovia. Pertanto, l'IF può comunicare soltanto gli ETI riferiti al terminale intermodale.

Spetta all'IFR effettuare il raffronto tra l'ETA e gli impegni assunti nei confronti del cliente.

Gli scostamenti rispetto all'ETA comunicato al cliente devono essere trattati secondo gli accordi contrattuali e possono dare avvio ad un processo di gestione dell'allerta da parte dell'IFR. Per la trasmissione delle informazioni sul risultato di questo processo, è previsto un messaggio di allerta.

Per generare un messaggio di allerta, l'IFR deve poter chiedere informazioni sugli scostamenti relativi al carro. Le caratteristiche di questa richiesta di informazioni e della risposta dell'IF sono precisate più avanti.

4.2.7.3.   Messaggio ETI/ETA del carro

Scopo	:	invio dell'ETI o dell'ETI aggiornato da un'IF all'IF successiva della catena di trasporto. L'ultima IF della catena di trasporto dei carri invia l'ETA o l'ETA aggiornato all'IFR.
Dati principali	:	— identificativo dell'IF che ha prodotto l'ETI o ETA, — stazione di partenza o stazione di interscambio precedente (ETI o orario di partenza dalla stazione di origine), — numero del treno in partenza dalla stazione di partenza o dalla stazione di interscambio precedente (dall'ETI o orario di partenza dalla stazione di origine), — data e orario effettivi di partenza del treno, — stazione di arrivo o stazione di interscambio successiva (ETI/ETA a destino), — numero del treno in arrivo alla stazione di destino per l'ETI/ETA (stazione di arrivo o stazione di interscambio successiva), — data e orario di arrivo del carro (ETI o ETA).

4.2.7.4.   Messaggio di allerta

Scopo	:	una volta effettuato il confronto tra l'ETA e l'orario indicato negli impegni contrattuali con il cliente, l'IFR può inviare un messaggio di allerta alle IF interessate.
Dati principali	:	— numero del carro, — impegni contrattuali con il cliente: data e orario di arrivo, — ETA effettivo: data e orario.

Nota: nella modalità di accesso libero il calcolo dell'ETI e dell'ETA costituisce un processo interno dell'IF. In questo caso, la stessa IF assume la funzione di IF responsabile.

4.2.7.5.   Richiesta di informazioni sugli scostamenti del carro

Scopo	:	si tratta del messaggio che l'IFR invia per chiedere informazioni sugli scostamenti relativi a un carro specifico.
Richiesta	:	dati principali — numero del carro, — identificativo dell'IFR.
Risposta	:	informazioni — per ciascun punto di segnalazione: — località di comunicazione, — stato del carro al punto di segnalazione (partenza, arrivo al piazzale, partenza dal piazzale, partenza dal piazzale, arrivo all'interscambio, arrivo al piazzale di destinazione), — IF su cui ricade la responsabilità per il carro nella località di segnalazione e stato corrispondente del carro al punto di segnalazione, — orario riprogrammato (rispetto all'orario corrente nell'ipotesi di più riprogrammazioni), — ETI, se il punto di segnalazione è un punto di interscambio, — orario effettivo al punto di segnalazione; — per ciascuno scostamento al punto di segnalazione: — codice del motivo e entità del ritardo per tale motivo.

4.2.8.   Movimenti del carro

4.2.8.1.   Note preliminari

Per le comunicazioni riguardanti i movimenti di un carro, i dati seguenti devono essere conservati e resi accessibili elettronicamente, nonché scambiati, in forma di messaggio, con i soggetti autorizzati (secondo le disposizioni contrattuali). Il formato dettagliato dei messaggi è precisato nel documento 1 di cui all'allegato A.

—	Avviso di messa a disposizione del carro

—	Avviso di partenza del carro

—	Arrivo del carro al piazzale

—	Partenza del carro dal piazzale

—	Imprevisti del carro

—	Avviso di arrivo del carro

—	Avviso di consegna del carro

—	Conferma di consegna del carro.

—	Le comunicazioni di interscambio relative ai carri sono descritte separatamente al paragrafo 4.2.9: Comunicazioni di interscambio.

4.2.8.2.   Avviso di messa a disposizione del carro

Scopo	:	l'IF responsabile non è necessariamente la prima IF della catena di trasporto. In tal caso, l'IFR utilizza questo messaggio per comunicare all'IF competente che il carro è pronto per essere preso in carico presso il raccordo del cliente (luogo di partenza secondo gli impegni assunti dall'IFR) a un orario specificato (data e orario di partenza). L'evento va registrato nella banca dati operativa dei carri e delle unità intermodali.
Dati principali	:	— numero del carro, — luogo, data e orario di partenza (luogo dal quale è programmata la partenza di un trasporto). L'IF e l'IFR devono poter accedere facilmente ai dati seguenti, conservati in banche dati: — unità di trasporto, identificativo, dimensioni e tipo, — capacità unitaria utilizzata, — peso totale [peso (massa) totale prenotato/effettivo delle merci, compresi gli imballaggi e le unità del vettore], — indicazione delle merci pericolose.

4.2.8.3.   Avviso di partenza del carro

Scopo	:	si tratta del messaggio con cui l'IF comunica all'IFR la data e l'orario effettivi in cui il carro ha lasciato il luogo di partenza. L'evento va registrato nella banca dati operativa dei carri e delle unità intermodali. Con questo messaggio la responsabilità per il carro passa dal cliente all'IF.
Dati principali	:	— numero del carro, — luogo, data e orario di partenza (luogo da cui è programmata la partenza del trasporto). L'IF e l'IFR devono poter accedere facilmente ai dati seguenti, conservati in banche dati: — unità di trasporto, identificativo, dimensioni e tipo, — capacità unitaria utilizzata, — peso totale [peso (massa) totale prenotato/effettivo delle merci, compresi gli imballaggi e le unità del vettore], — indicazione delle merci pericolose.

4.2.8.4.   Arrivo del carro al piazzale

Scopo	:	si tratta del messaggio con cui l'IF comunica all'IFR che il carro è giunto presso il proprio piazzale; può corrispondere a un Avviso di treno in marcia, descritto al paragrafo 4.2.4 (Previsione di marcia del treno). L'evento va registrato nella banca dati operativa dei carri e delle unità intermodali.
Dati principali	:	— numero del carro, — identificativo del piazzale di arrivo, — data e orario di arrivo al piazzale.

4.2.8.5.   Messaggio Partenza del carro dal piazzale

Scopo	:	l'IF deve comunicare all'IFR che il carro ha lasciato il proprio piazzale. Il messaggio può corrispondere a un Avviso di treno in marcia descritto al paragrafo 4.2.4 (Previsione di marcia del treno). L'evento va registrato nella banca dati operativa dei carri e delle unità intermodali.
Dati principali	:	— numero del carro, — identificativo del piazzale di partenza, — data e orario di partenza dal piazzale.

4.2.8.6.   Imprevisti del carro

Scopo	:	si tratta del messaggio con cui l'IF comunica all'IFR il verificarsi di un imprevisto che potrebbe avere ripercussioni sull'ETI/ETA o che richiede un intervento. Nella maggior parte dei casi, il messaggio rende necessario il calcolo di un nuovo ETI/ETA. Se l'IFR decide che deve essere calcolato un nuovo ETI/ETA, invia un messaggio all'IF da cui ha avuto origine questo messaggio, unendo la richiesta di un nuovo ETI/ETA (Imprevisti del carro – Richiesta di nuovo ETI/ETA). Il nuovo ETI/ETA deve essere calcolato secondo la procedura di cui al paragrafo 4.2.7 (ETI/ETA della spedizione). Questa informazione va registrata nella banca dati operativa dei carri e delle unità intermodali.
Dati principali	:	— numero del carro, — luogo, data e orario della perturbazione (luogo in cui si è verificato un imprevisto durante il trasporto), — motivo/codice della perturbazione. Deve essere inoltre garantito un accesso agevole ai dati seguenti, conservati in banche dati: — dati identificativi dell'unità di trasporto, — indicazione delle merci pericolose.

4.2.8.7.   Imprevisti del carro — Richiesta di nuovo ETI/ETA

Scopo	:	si tratta del messaggio che l'IFR può inviare all'IF che ha trasmesso il messaggio Imprevisti del carro, per chiedere che venga calcolato un nuovo ETI/ETA. Il messaggio viene inviato dall'IFR anche a tutte le IF successive per informarle degli scostamenti. Non è sempre necessario calcolare un nuovo ETI/ETA; spetta all'IFR decidere se occorre farlo.
Dati principali	:	— numero del carro, — luogo, data e orario della perturbazione (luogo in cui si è verificato un imprevisto durante il trasporto), — motivo/codice della perturbazione, — richiesta di nuovo ETI/ETA. Deve essere inoltre garantito un accesso agevole ai dati seguenti, conservati in banche dati: — dati identificativi dell'unità di trasporto, — indicazione delle merci pericolose.

4.2.8.8.   Avviso di arrivo del carro

Scopo	:	si tratta del messaggio con cui l'ultima IF di una catena di trasporto di carri o unità intermodali comunica all'IFR l'arrivo del carro presso il proprio piazzale (località dell'IF).
Dati principali	:	— numero del carro, — identificativo del piazzale dell'IF, — data e orario di arrivo.

4.2.8.9.   Avviso di consegna del carro

Scopo	:	si tratta del messaggio con cui l'ultima IF di una catena di trasporto di carri comunica all'IFR che il carro è stato collocato sui raccordi del destinatario.
Dati principali	:	— numero del carro, — identificativo della collocazione sui raccordi del destinatario (località, zona, binario, sezione), — data e orario della collocazione.

L'Avviso di consegna del carro può essere inviato una seconda volta sotto forma di Conferma di consegna del carro contenente la seguente informazione aggiuntiva:

—	identificativo del cliente.

Nota: in caso di accesso libero, i movimenti del carro costituiscono un processo interno all'IF (IFR). Tuttavia, l'IF deve ugualmente eseguire tutti i calcoli e conservare tutti i dati, in quanto avendo stipulato un contratto e assunto impegni nei confronti del cliente essa opera in qualità di IFR.

Il diagramma della sequenza relativa a questi messaggi, basato sull'esempio 1 per il calcolo dell'ETI relativo ai carri 1 e 2 (cfr. paragrafo 4.2.7.2: Calcolo dell'ETI/ETA), è inserito all'interno del diagramma relativo alle comunicazioni di interscambio illustrato nel documento 5, capitolo 6, di cui all'allegato A.

4.2.9.   Comunicazioni di interscambio

4.2.9.1.   Nota preliminare

Le comunicazioni di interscambio descrivono i messaggi utilizzati per segnalare il trasferimento della responsabilità di un carro da un'IF a un'altra IF in corrispondenza di un punto di interscambio. Ad ogni interscambio, la nuova IF deve calcolare l'ETI e seguire la procedura descritta al paragrafo 4.2.7 (ETI/ETA della spedizione).

I messaggi utilizzati sono i seguenti:

—	Avviso di interscambio carro,

—	Avviso di interscambio carro/sottoinsieme,

—	Carro ricevuto all'interscambio,

—	Carro rifiutato all'interscambio.

I dati di questi messaggi devono essere conservati nella banca dati operativa dei carri e delle unità intermodali. Nell'eventualità di un qualsiasi scostamento, deve essere calcolato un nuovo ETI/ETA, che deve essere comunicato secondo la procedura descritta al paragrafo 4.2.7: ETI/ETA della spedizione. Il diagramma della sequenza di questi messaggi è illustrato, in relazione ai messaggi dei movimenti del carro, nel documento 5, capitolo 6, di cui all'allegato A.

Gli avvisi di interscambio carro e gli avvisi di interscambio carro/sottoinsieme, come pure i messaggi di carro ricevuto, possono essere trasferiti sotto forma di elenco per vari carri, specialmente se i carri fanno tutti parte di un unico treno. In questo caso, tutti i carri possono essere elencati in uno stesso trasferimento di messaggi.

Nella modalità di accesso libero non vi sono punti di interscambio. Nei punti di manipolazione non vi è alcun passaggio di responsabilità in relazione ai carri, quindi non occorre uno specifico scambio di messaggi. Tuttavia, dalle informazioni sulla marcia del treno in corrispondenza dei punti di segnalazione vengono ricavate informazioni sul carro o sull'unità intermodale — luogo e data/orario di arrivo e di partenza — che devono essere elaborate e conservate nella banca dati operativa dei carri e delle unità intermodali.

Il contenuto dei messaggi è descritto di seguito.

4.2.9.2.   Avviso di interscambio carro

Scopo	:	si tratta del messaggio con cui un'impresa ferroviaria (IF 1) chiede all'impresa ferroviaria che le succede nella catena di trasporto (IF 2) se accetta la responsabilità relativa al carro. Con l'Avviso di interscambio carro/sottoinsieme, l'IF 2 informa il GI di aver accettato la responsabilità.
Dati principali	:	— numero del carro, — numero del treno (solo se il carro fa parte di un treno), — luogo, data e ora dell'interscambio. Deve essere inoltre garantito un accesso agevole ai dati seguenti, conservati in banche dati: — dati identificativi dell'unità di trasporto (numero, dimensioni, tipo), — peso totale [peso (massa) totale prenotato/effettivo delle merci, compresi gli imballaggi e le unità del vettore], — capacità unitaria utilizzata, — informazioni sulle merci pericolose, codici identificativi.

4.2.9.3.   Avviso di interscambio carro/sottoinsieme

Scopo	:	si tratta del messaggio con cui l'IF 2 comunica al GI di aver assunto la responsabilità relativa a un determinato carro.
Dati principali	:	— numero del carro, — numero del treno (solo se il carro fa parte di un treno), — luogo, data e ora dell'interscambio. Deve essere inoltre garantito un accesso agevole ai dati seguenti, conservati in banche dati: — informazioni sulle merci pericolose, codici identificativi.

4.2.9.4.   Carro ricevuto all'interscambio

Scopo	:	si tratta del messaggio con cui l'IF 2 comunica all'IF l'accettazione della responsabilità relativa al carro.
Dati principali	:	— numero del carro, — luogo, data e ora dell'interscambio.

4.2.9.5.   Carro rifiutato all'interscambio

Scopo	:	si tratta del messaggio con cui l'IF 2 comunica all'IF 1 di non essere disposta ad assumere la responsabilità relativa al carro.
Dati principali	:	— numero del carro, — luogo, data e ora dell'interscambio, — codice del motivo del rifiuto, — ulteriore descrizione (facoltativa).

4.2.10.   Scambio di dati a fini di miglioramento della qualità

Per essere competitivo, il settore ferroviario europeo deve migliorare la qualità del servizio fornito ai clienti (cfr. anche allegato III, paragrafo 2.7.1, della direttiva 2001/16/CE).

Un processo di valutazione a conclusione del viaggio è un elemento essenziale per realizzare miglioramenti qualitativi.

Oltre alla valutazione della qualità del servizio fornito al cliente, le IFR, le altre IF e i GI devono misurare la qualità degli elementi che concorrono a formare il prodotto fornito al cliente.

I GI e le IF (in particolare le IF responsabili) attuano questo processo selezionando un singolo parametro di qualità, un itinerario o una località e un periodo per i quali valutare i risultati effettivi rispetto a criteri prestabiliti, normalmente indicati in un contratto.

I risultati del processo di valutazione devono indicare in modo chiaro il livello di conseguimento dell'obiettivo concordato tra le parti contraenti.

Per la predisposizione delle relazioni di valutazione deve essere garantito l'accesso a dettagli sufficienti a permettere di inserire nell'analisi l'indicazione del luogo e del motivo apparente delle riduzioni della qualità, ad es. i ritardi. Per le carenze ripetitive di qualità deve essere quindi eseguita un'analisi delle cause a monte, in modo che le parti contraenti possano definire gli opportuni correttivi.

I GI e le IF hanno l'obbligo di mettere a disposizione i dati, partecipare all'analisi delle cause a monte, anche insieme a soggetti terzi, e attuare i correttivi eventualmente decisi.

Il processo di misurazione è di tipo ripetitivo.

Per misurare la qualità si possono utilizzare i messaggi già descritti, raggruppati nei sei punti seguenti:

1.   IFR/cliente: orario di transito, ETA, risoluzione delle allerte

I contratti tra IF operanti in qualità di integratori di servizi (IFR) e clienti possono prevedere, a seconda degli accordi, impegni relativi all'orario di transito, all'ETA e alla risoluzione delle allerte. I messaggi che hanno maggiore rilevanza per la misurazione di questi aspetti della qualità sono:

Avviso di messa a disposizione,

Avviso di partenza,

Avviso di consegna.

2.   IFR/erogatori di servizi: orari di transito e di manipolazione, ETA, ETI, codici dei motivi

I contratti tra l'IFR e gli altri soggetti erogatori di servizi di trasporto possono prevedere impegni relativi agli orari di transito nei confronti di singoli soggetti erogatori di servizi per quanto segue:

dal termine per la messa a disposizione/orario di traino alla consegna all'interscambio,

dal prelevamento all'ingresso,

dall'ingresso al carico,

dal ricevimento all'interscambio alla consegna all'interscambio,

dal ricevimento all'interscambio alla collocazione/collocazione costruttiva,

dalla collocazione a terra alla consegna.

I messaggi che hanno maggiore rilevanza per la misurazione di questi aspetti della qualità sono:

Avviso di rilascio,

Avviso di partenza,

Arrivo al piazzale,

Partenza dal piazzale,

Avviso di arrivo,

Carro consegnato all'interscambio,

Carro ricevuto all'interscambio,

Carro rifiutato all'interscambio.

3.   IF/GI: prestazioni del treno, ETA del treno (TETA), ETH

I contratti tra IF e GI possono precisare specifici livelli di puntualità in determinati punti di segnalazione, nonché specifici livelli di accuratezza degli ETA ed ETH dei treni. I messaggi che hanno maggiore rilevanza per la misurazione di questi aspetti della qualità sono:

Previsione di marcia del treno,

Avviso di treno in marcia,

Richiesta di informazioni/Risposta riguardo al ritardo/prestazioni di un treno.

4.   IF/GI: disponibilità della traccia oraria/programmata

Nei contratti tra IF e GI, si deve descrivere con chiarezza la disponibilità di tracce orarie per la circolazione di treni, in termini di fascia oraria in corrispondenza di punti specifici. I contratti devono anche precisare le caratteristiche del treno: lunghezza massima, peso lordo, sagoma limite di carico ecc. Questi aspetti sono trattati più avanti al punto 6 (GI/IF: qualità della composizione del treno).

Nei contratti si devono precisare anche le procedure e la tempistica per la conferma dell'utilizzo di una traccia oraria, l'annullamento di una traccia programmata e la possibilità di utilizzare una traccia al di fuori della fascia oraria stabilita (anticipo o differimento). I messaggi che hanno maggiore rilevanza per la misurazione di questi aspetti della qualità sono:

Traccia oraria annullata,

Traccia oraria non disponibile.

5.   IF/GI: disponibilità di tracce orarie in gestione operativa

Se un'IF vuole far circolare un treno al di fuori dei limiti di tempo stabiliti per una traccia oraria programmata, deve inviare una richiesta di traccia in gestione operativa al GI o ai GI interessati (conformemente a quanto disposto dalla direttiva 2001/14/CE).

L'IF deve raffrontare periodicamente le richieste di tracce e i dati delle risposte al fine di produrre le seguenti relazioni:

tempo di risposta alle richieste di tracce rispetto all'accordo quadro,

numero di tracce fornite entro determinati termini di tempo dal momento della richiesta,

numero di richieste di tracce respinte.

I messaggi che hanno maggiore rilevanza per la misurazione di questi aspetti della qualità sono:

Richiesta di traccia oraria,

Dettagli della traccia oraria,

Dettagli della traccia oraria respinti,

Traccia oraria annullata,

Traccia oraria non disponibile.

6.   GI/IF: qualità della composizione del treno

La composizione del treno indicata nei messaggi di treno pronto e/o nelle liste di veicoli che l'IF invia al o ai GI (o ad altre IF) deve essere conforme a quella precisata nel contratto. I messaggi che hanno maggiore rilevanza per il controllo della conformità e quindi per la misura della qualità della composizione sono:

Composizione del treno,

Treno non compatibile.

4.2.11.   Principali dati di riferimento

4.2.11.1.   Introduzione

I dati sull'infrastruttura (prospetti informativi della rete e contenuto della banca dati degli avvisi di restrizione dell'infrastruttura) e i dati sul materiale rotabile (contenuto delle banche dati di riferimento sul materiale rotabile e della banca dati operativa dei carri e delle unità intermodali) sono i più importanti ai fini della circolazione dei treni merci sulla rete europea. Insieme, essi permettono di valutare la compatibilità del materiale rotabile con l'infrastruttura, contribuiscono ad evitare ripetizioni nell'immissione dei dati (con vantaggi evidenti sul piano della qualità) e offrono un quadro chiaro di tutti gli impianti e le installazioni disponibili in qualsiasi momento, creando così le condizioni per decisioni rapide in fase di esercizio.

4.2.11.2.   Banche dati degli avvisi di restrizione dell'infrastruttura

Ciascun GI è responsabile dell'idoneità di ogni traccia oraria rispetto alle caratteristiche della sua infrastruttura; da parte sua, l'IF è tenuta a verificare le caratteristiche del treno rispetto ai valori indicati nei dettagli della traccia oraria contrattualizzata.

Ferme restando le condizioni indicate nei prospetti informativi delle reti per l'uso delle tracce e le responsabilità in caso di eventuali restrizioni dell'infrastruttura illustrate nella STI Esercizio e gestione del traffico, l'IF deve sapere, prima di preparare il treno, se nei tratti di linea o nelle stazioni (nodi) vi sono restrizioni tali da rendere necessaria la modifica della composizione del treno descritta nel contratto relativo alla traccia.

A tal fine, ciascun GI deve provvedere alla creazione e all'aggiornamento di una banca dati degli avvisi di restrizione dell'infrastruttura. La struttura di tale banca dati è illustrata schematicamente nel documento 2 di cui all'allegato A. I dati contenuti in queste banche dati sono riferiti ai vari tratti di linea indicati nei prospetti informativi delle reti, e comprendono informazioni relative alle restrizioni. L'accesso a queste banche dati deve essere possibile attraverso l'interfaccia comune (4.2.14.1: Architettura generale e 4.2.14.7: Interfaccia comune).

Prima del periodo prepartenza, l'IF deve tenersi aggiornata in merito a tutte le restrizioni indicate nella banca dati degli avvisi di restrizione dell'infrastruttura che potrebbero avere ripercussioni sulla circolazione del suo treno, e tenerle nella dovuta considerazione. Se non diversamente indicato nel contratto tra GI e IF, il periodo prepartenza ha inizio un'ora prima dell'orario programmato di partenza.

Nel periodo prepartenza il GI deve comunicare direttamente all'IF eventuali variazioni rilevanti intervenute nella banca dati degli avvisi di restrizione dell'infrastruttura.

4.2.11.3.   Banche dati di riferimento sul materiale rotabile

Ciascun titolare di materiale rotabile è tenuto a conservare i dati sul materiale rotabile in una banca dati di riferimento sul materiale rotabile.

Le informazioni che devono essere incluse nelle singole banche dati di riferimento sul materiale rotabile sono descritte in modo particolareggiato nel documento 2 di cui all'allegato A. Le banche dati devono contenere tutti gli elementi relativi a:

—	identificazione del materiale rotabile,

—	valutazione della compatibilità con l'infrastruttura,

—	valutazione delle caratteristiche di caricamento pertinenti,

—	caratteristiche pertinenti dei freni,

—	dati sulla manutenzione,

—	caratteristiche ambientali.

Le banche dati di riferimento sul materiale rotabile devono consentire un accesso agevole (accesso unico comune attraverso l'interfaccia comune) ai dati tecnici, in modo da ridurre al minimo il volume dei dati trasmessi per ciascuna operazione. Al contenuto delle banche dati devono poter accedere, in base a diritti di accesso strutturati in funzione dei privilegi, tutti i soggetti erogatori di servizi (GI, IF, fornitori di servizi logistici e gestori di parchi rotabili) in particolare per finalità connesse alla gestione dei parchi rotabili e alla manutenzione del materiale rotabile.

I dati contenuti nelle banche dati di riferimento sul materiale rotabile possono essere organizzati nel modo seguente.

—

Dati amministrativi Si riferiscono a certificazioni e immatricolazioni, ad esempio il riferimento al fascicolo di immatricolazione CE, i dati identificativi dell'organismo notificato, ecc.; possono comprendere anche dati storici relativi alla proprietà, alla locazione, ecc. Si devono considerare le seguenti procedure: — certificazione CE, — immatricolazione nello Stato di appartenenza, — data di messa in servizio nello Stato di immatricolazione, — immatricolazione in altri paesi per l'impiego sulle rispettive reti nazionali, — certificazione di sicurezza per tutto il materiale rotabile non rispondente alla STI Materiale rotabile. Il titolare è tenuto a garantire la disponibilità di questi dati e ad accertarsi che le procedure a cui essi si riferiscono siano state esperite.

—

Dati di progetto Riguardano tutti gli elementi (fisici) costitutivi del materiale rotabile e comprendono le caratteristiche ambientali, nonché tutte le informazioni che si prevede rimarranno valide per tutta la vita di esercizio del materiale rotabile. Nei dati di progetto può essere compresa la cronologia delle principali modifiche, dei principali interventi di manutenzione, revisione, ecc.

4.2.11.4.   Dati operativi del materiale rotabile

Oltre ai dati di riferimento sul materiale rotabile, i dati più importanti ai fini dell'esercizio sono quelli che indicano lo stato effettivo dei rotabili.

Tali dati comprendono dati temporanei quali restrizioni, interventi di manutenzione correnti e previsti, computo dei km e dei guasti, ecc., nonché tutti i dati che in qualche modo riguardano lo «stato» del materiale rotabile (restrizioni temporanee di velocità, freni isolati, riparazioni necessarie e descrizione dei guasti, ecc.).

Per l'uso dei dati operativi del materiale rotabile, occorre tener conto di tre soggetti diversi, che corrispondono alle diverse figure sotto la cui responsabilità sono posti i rotabili durante il trasporto:

—	impresa ferroviaria, in quanto soggetto obbligato durante il controllo del trasporto,

—	titolare del materiale rotabile,

—	utilizzatore (locatario) del materiale rotabile.

Per tutti e tre questi soggetti, gli utenti autorizzati devono poter accedere ai dati operativi del materiale rotabile, fino al rispettivo livello autorizzato predefinito, utilizzando come unica chiave l'identificativo del carro (numero del carro).

I dati operativi del materiale rotabile fanno parte di una banca dati operativa dei carri e delle unità intermodali su scala europea, descritta al paragrafo 4.2.12.2: Altre banche dati.

4.2.12.   Archivi di riferimento e banche dati varie

4.2.12.1.   Archivi di riferimento

Per la circolazione dei treni merci sulla rete europea, deve essere garantita la disponibilità dei seguenti archivi di riferimento e così pure la possibilità di accesso a tali archivi da parte di tutti i soggetti erogatori di servizi (GI, IF, fornitori di servizi logistici e gestori di parchi rotabili). I dati devono rappresentare in qualsiasi momento la situazione effettiva.

Archivi conservati e amministrati a livello locale:

—	archivio dei servizi di emergenza, correlati al tipo di merce pericolosa.

Archivi conservati e amministrati a livello centrale:

—	archivio dei codici di tutti i GI, IF e soggetti erogatori di servizi,

—	archivio dei codici dei clienti dei servizi di trasporto,

—	archivio dei codici delle località (primaria, sussidiaria e zona-binario-sezione),

—	archivio dei codici delle sedi dei clienti,

—	archivio di tutti i sistemi di controllo dei treni disponibili,

—	archivio delle merci pericolose (numeri ONU e RID),

—	archivio dei diversi tipi di locomotive,

—	archivio dei codici CN e HS delle merci,

—	archivio delle officine europee di manutenzione,

—	archivio degli organismi europei di verifica ispettiva,

—	archivio degli operatori europei titolari di licenza, con l'elenco dei certificati nazionali di sicurezza rilasciati.

I codici relativi a GI, IF, organizzazioni e imprese di trasporto, clienti dei servizi di trasporto e località (primaria, sussidiaria, ecc.), comprese le sedi dei clienti, sono in via di definizione.

4.2.12.2.   Altre banche dati

Per assicurare la tracciabilità dei movimenti di treni e carri, è necessario garantire l'operatività delle banche dati indicate in appresso, nonché il loro aggiornamento in tempo reale a seguito di ogni evento rilevante. I soggetti autorizzati, quali i titolari e i gestori dei parchi rotabili, devono poter accedere ai dati pertinenti per esercitare le proprie funzioni, conformemente alle condizioni contrattuali.

—	Banca dati operativa dei carri e delle unità intermodali,

—	Banca dati dei piani di inoltro dei carri/unità intermodali.

L'accesso a queste banche dati deve essere possibile attraverso l'interfaccia comune (4.2.14.1: Architettura generale e 4.2.14.7: Interfaccia comune).

Banca dati operativa dei carri e delle unità intermodali

La comunicazione tra l'IF responsabile e le altre IF, nella modalità in cooperazione, si basa sui numeri di carro e/o di unità intermodale. Quando un'IF comunica con il GI riferendosi a un treno, deve scomporre le informazioni per i singoli carri e unità intermodali. Queste informazioni devono essere conservate in un'apposita banca dati operativa dei carri e delle unità intermodali. Le informazioni sui movimenti del treno danno origine a nuovi inserimenti/aggiornamenti nella banca dati operativa dei carri e delle unità intermodali a cui il cliente può accedere. La parte della banca dati relativa ai movimenti di un carro o unità intermodale viene creata al più tardi al ricevimento dell'orario di messa a disposizione dei carri o delle unità intermodali comunicato dal cliente. Tale orario è il primo dato sui movimenti del carro inserito nella banca dati con riferimento a un percorso di trasporto effettivo. I messaggi relativi ai movimenti del carro sono descritti nei paragrafi 4.2.8 (Movimenti del carro) e 4.2.9 (Comunicazioni di interscambio). L'accesso a queste banche dati deve essere possibile attraverso l'interfaccia comune (4.2.14.1: Architettura generale e 4.2.14.7: Interfaccia comune).

La banca dati operativa dei carri e delle unità intermodali è la più importante per la localizzazione dei carri e quindi per le comunicazioni tra le IF che partecipano al trasporto e l'IF responsabile. Questa banca dati indica i movimenti di ogni carro e unità intermodale dalla partenza fino alla consegna finale al raccordo del cliente, con gli ETI e gli orari effettivi in diverse località fino all'orario della consegna finale (ETA). La banca dati indica anche lo stato di ogni rotabile.

—	Stato: carico del rotabile

Questo stato deve essere indicato nello scambio di informazioni tra l'IF e i GI e deve essere comunicato ad altre imprese ferroviarie che intervengono nel trasporto.

—	Stato: carro carico in viaggio

Questo stato deve essere indicato nello scambio di informazioni tra il GI e l'IF, con altri gestori dell'infrastruttura e con altre imprese ferroviarie che intervengono nel trasporto.

—	Stato: carro vuoto in viaggio

Questo stato deve essere indicato nello scambio di informazioni tra il GI e l'IF, con altri gestori dell'infrastruttura e con imprese ferroviarie che intervengono nel trasporto.

—	Stato: scarico del rotabile

Questo stato deve essere indicato nello scambio di informazioni tra l'IF a destinazione e l'IF responsabile per il trasporto.

—	Stato: carro vuoto in gestione parco rotabile

Questo stato deve essere indicato per avere informazioni sulla disponibilità di un veicolo con determinate caratteristiche.

Banche dati dei piani di inoltro dei carri

In un treno normalmente sono presenti carri di clienti diversi. Per ciascun carro, l'IF responsabile (IF che opera in qualità di integratore del servizio) deve creare e aggiornare un piano di inoltro che corrisponde (a livello di treno) al percorso della traccia oraria. Se viene definita una nuova traccia oraria per il treno, per esempio a causa di un'interruzione del servizio, è necessario rivedere il piano di inoltro dei carri in composizione al treno. Il piano di inoltro viene creato al ricevimento della lettera di vettura inviata dal cliente.

I piani di inoltro dei carri devono essere conservati da ciascuna IFR in una banca dati. L'accesso a queste banche dati deve essere possibile attraverso l'interfaccia comune (4.2.14.1: Architettura generale e 4.2.14.7: Interfaccia comune).

Nota:

Oltre alle banche dati obbligatorie indicate in precedenza, ciascun GI può creare una banca dati treni.

La banca dati treni del GI corrisponde alla parte relativa al movimento della banca dati operativa dei carri e delle unità intermodali. I dati principali da inserire sono i dati relativi al treno contenuti nel messaggio di composizione del treno inviato dall'IF. Tutti gli eventi relativi al treno comportano un aggiornamento della banca dati treni. In alternativa, questi dati possono essere inseriti nella banca dati delle tracce orarie (paragrafo 4.2.2: Richiesta di traccia oraria). L'accesso a queste banche dati deve essere possibile attraverso l'interfaccia comune (4.2.14.1: Architettura generale e 4.2.14.7: Interfaccia comune).

4.2.12.3.   Altri requisiti delle banche dati

Le varie banche dati (database) devono soddisfare anche altri requisiti indicati di seguito.

Tali requisiti sono.

1)	Autenticazione Prima di poter accedere al contenuto dei database, gli utenti devono passare attraverso una fase di autenticazione.

2)	Sicurezza dei dati Deve essere garantita la sicurezza dei database attraverso il controllo dell'accesso agli stessi. Non è richiesta la cifratura del contenuto dei database.

3)	Consistenza I database devono soddisfare il principio ACID (Atomicità, Consistenza, Isolamento, Durabilità).

4)

Controllo dell'accesso L'accesso ai dati dei database deve essere consentito soltanto agli utenti o ai sistemi che dispongono della necessaria autorizzazione. Il controllo dell'accesso, che deve estendersi fino ai singoli attributi dei record di dati, deve essere configurabile e basato sul ruolo per le operazioni di inserimento, aggiornamento o cancellazione dei record.

5)	Rintracciabilità I database devono registrare tutte le azioni effettuate al loro interno per consentire la rintracciabilità dei dettagli relativi all'inserimento dei dati (autore, oggetto, momento di ogni variazione del contenuto).

6)	Strategia di bloccaggio I database devono applicare una strategia di bloccaggio per consentire l'accesso ai dati anche mentre è in corso la modifica dei record da parte di altri utenti.

7)	Accesso multiplo I database devono consentire a più utenti e sistemi di accedere contemporaneamente ai dati.

8)	Affidabilità L'affidabilità dei database non deve essere di impedimento alla necessaria disponibilità.

9)	Disponibilità La disponibilità su richiesta dei database deve essere non inferiore al 99,9 %.

10)	Manutenibilità La manutenibilità dei database deve garantire la disponibilità necessaria.

11)

Sicurezza della circolazione I database non hanno attinenza con la sicurezza della circolazione, pertanto gli aspetti legati alla sicurezza intesa in tal senso non hanno rilevanza. Ciò non va confuso con il fatto che la presenza di dati errati o non aggiornati può avere ripercussioni sulla sicurezza della circolazione di un treno.

12)	Compatibilità I database devono consentire l'utilizzo di uno dei linguaggi più diffusi per la manipolazione dei dati, ad esempio SQL o XQL.

13)	Funzione di importazione I database devono prevedere una funzione che consenta di importare dati formattati anziché inserirli manualmente.

14)	Funzione di esportazione I database devono prevedere una funzione che consenta di esportare, sotto forma di dati formattati, l'intero contenuto o parte di esso.

15)	Campi obbligatori I database devono prevedere l'obbligatorietà della compilazione di alcuni campi ai fini dell'accettazione dei record corrispondenti come dati inseriti nel database.

16)	Controlli di plausibilità I database devono prevedere controlli di plausibilità configurabili prima di accettare l'inserimento, l'aggiornamento o la cancellazione di record.

17)	Tempi di risposta I database devono avere tempi di risposta che garantiscano la tempestività delle operazioni di inserimento, cancellazione o aggiornamento dei record.

18)

Aspetti legati alle prestazioni I database devono essere in grado di gestire le interrogazioni necessarie a consentire la circolazione efficiente di circa 60 000 treni nelle 24 ore. Si stima che circa il 50 % delle corse si concentri nell'arco di due ore. Il numero e il tipo delle interrogazioni o degli aggiornamenti per ciascun treno dipendono dal processo complessivo di pianificazione ed esercizio dei treni.

19)

Aspetti legati alla capacità I database devono essere in grado di conservare i dati aventi rilevanza per tutti i carri merci che impegnano la rete. La capacità dei database deve poter essere ampliata in modo semplice (vale a dire aumentando la capacità di memorizzazione e il numero di computer). L'ampliamento della capacità deve poter essere eseguito senza sostituire il sottosistema.

20)	Dati storici I database devono essere in grado di gestire i dati storici mettendo a disposizione i dati già trasferiti in un archivio storico.

21)	Strategia di backup Deve essere applicata una strategia di backup che permetta di recuperare tutti i dati relativi ad un periodo fino a 24 ore.

22)	Aspetti commerciali Il sistema utilizzato deve essere un prodotto disponibile in commercio (COTS) o di tipo «public domain» (Open Source).

Note:

I requisiti sopra indicati devono essere soddisfatti da un sistema per la gestione di database (DBMS) di tipo standard.

L'uso dei vari database è alla base di vari flussi di lavoro descritti in precedenza. Il flusso di lavoro generale è un meccanismo di richiesta/risposta attraverso il quale un soggetto interessato chiede informazioni contenute nel database attraverso l'interfaccia comune (4.2.14.1: Architettura generale e 4.2.14.7: Interfaccia comune). Il DBMS risponde alla richiesta fornendo i dati richiesti o precisando che tali dati non possono essere messi a disposizione (perché non esistono o perché l'accesso non è consentito in base alle regole sul controllo dell'accesso).

4.2.13.   Trasmissione elettronica dei documenti

Il paragrafo 4.2.14 (Reti e comunicazioni) descrive la rete di comunicazione da usare per lo scambio di dati. Tale rete e le relative procedure di sicurezza permettono qualsiasi tipo di trasmissione in rete, ovvero e-mail, trasferimento di file (ftp, http), ecc. La scelta del tipo di trasmissione è lasciata alle parti che intervengono nello scambio di informazioni, le quali possono concordare di effettuare la trasmissione elettronica dei documenti per esempio tramite protocollo ftp.

4.2.14.   Reti e comunicazioni

4.2.14.1.   Architettura generale

Questo sottosistema vedrà, col tempo, la crescita e l'interazione di una grande e complessa comunità telematica di interoperabilità ferroviaria composta da centinaia di soggetti (IF, GI, ecc.) che opereranno in concorrenza e/o cooperazione per rispondere alle necessità del mercato.

L'infrastruttura di rete e di comunicazione su cui opererà la comunità di interoperabilità ferroviaria si baserà su un'«architettura di scambio dati», conosciuta e adottata da tutti i soggetti partecipanti.

L'architettura di scambio dati proposta:

—	è concepita per conciliare modelli eterogenei di informazione mediante la trasformazione della semantica dei dati scambiati dai sistemi e l'armonizzazione dei processi commerciali e delle differenze tra protocolli di applicazione,

—	ha un impatto minimo sulle architetture IT attualmente usate dai partecipanti,

—	salvaguarda gli investimenti IT già effettuati.

Le architetture di scambio dati favoriscono un'interazione essenzialmente di tipo peer-to-peer tra tutti i soggetti e, al contempo, garantiscono l'integrità complessiva e la coerenza della comunità di interoperabilità ferroviaria fornendo un insieme di servizi centralizzati.

Il modello di interazione peer-to-peer consente una ripartizione ottimale dei costi basata sull'utilizzo effettivo e presenterà, in termini generali, minori problemi di scalabilità. Per una rappresentazione grafica dell'architettura generale si rimanda al documento 5, paragrafo 1.5, di cui all'allegato A.

4.2.14.2.   Rete

In questo contesto, per rete si intendono il metodo e la filosofia di comunicazione e non la rete fisica in quanto tale.

L'interoperabilità ferroviaria si basa su un'architettura di scambio dati conosciuta e adottata da tutti i partecipanti, in modo da favorire l'ingresso di nuovi soggetti, in particolare clienti, e ridurre gli eventuali ostacoli all'ingresso.

La sicurezza non verrà quindi gestita a livello di rete (VPN, tunnelling, ecc.) ma verrà garantita grazie allo scambio e alla gestione di messaggi intrinsecamente sicuri. Non si rende quindi necessaria una rete VPN, che per le sue dimensioni comporterebbe una notevole complessità e costi elevati; in questo modo si eviteranno i problemi legati alla ripartizione di competenze e proprietà. Non si ritiene necessario ricorrere al tunnelling per ottenere il livello di sicurezza opportuno.

In ogni caso, gli operatori possono avvalersi di livelli di sicurezza diversi su segmenti specifici della rete (alcuni lo hanno del resto già fatto).

La rete pubblica Internet permette di installare un modello ibrido peer-to-peer con un repository (deposito) centrale dei dati e un'interfaccia comune in ogni nodo.

Gli utenti accedono innanzitutto al repository centrale per ottenere metadati quali l'identità del «peer» (altro utente), consultando eventuali informazioni già registrate, o per verificare le credenziali di sicurezza. Successivamente viene avviata la comunicazione peer-to-peer.

4.2.14.3.   Protocolli

Possono essere usati solo protocolli che fanno parte della suite IP (Internet Protocol) completa.

4.2.14.4.   Sicurezza

Per ottenere un livello elevato di sicurezza, tutti i messaggi devono essere autonomi (in questo modo le informazioni contenute nel messaggio sono protette e il destinatario può verificarne l'autenticità). A tal fine si può ricorrere a sistemi di cifratura e di firma simili a quelli impiegati per la cifratura delle e-mail. Ciò rende possibile l'uso di qualsiasi tipo di trasmissione in rete, ovvero e-mail, trasferimento di file (ftp, http), ecc. La scelta del tipo di trasmissione è lasciata ai soggetti che partecipano allo scambio di informazioni.

4.2.14.5.   Cifratura

Si deve ricorrere ad una cifratura asimmetrica o ad una soluzione ibrida basata sulla cifratura simmetrica con protezione mediante chiave pubblica in quanto, nel lungo termine, la condivisione di una chiave segreta comune tra molti operatori risulta inefficace. È più facile raggiungere un livello più elevato di sicurezza se ogni soggetto assume la responsabilità del proprio paio di chiavi, per quanto ciò esiga un alto livello di integrità del repository centrale (il server di chiavi).

4.2.14.6.   Repository centrale

Il repository centrale deve essere in grado di gestire:

—	metadati (dati strutturati che descrivono il contenuto dei messaggi),

—	Public Key Infrastructure (PKI) — dati di infrastruttura a chiave pubblica,

—	certificati originali forniti dalla Certification Authority (CA),

—	directory («elenco telefonico») contenente tutte le informazioni sui partecipanti necessarie allo scambio di messaggi.

La gestione del repository centrale dovrebbe essere affidata a un organismo co-europeo non commerciale.

4.2.14.7.   Interfaccia comune

Ogni soggetto che voglia aderire alla comunità dell'interoperabilità ferroviaria deve ricorrere all'interfaccia comune.

L'interfaccia comune deve essere in grado di gestire:

—	la formattazione dei messaggi in uscita in base ai metadati,

—	la firma e la cifratura dei messaggi in uscita,

—	l'indirizzamento dei messaggi in uscita,

—	la verifica dell'autenticità dei messaggi in arrivo,

—	la decifratura dei messaggi in arrivo,

—	la verifica della conformità dei messaggi in arrivo rispetto ai metadati,

—	l'accesso comune unico alle varie banche dati.

Ogni istanza dell'interfaccia comune ha accesso a tutti i dati richiesti in base alla STI e detenuti da ogni IF, GI, ecc., indipendentemente dal fatto che i database corrispondenti siano centralizzati o individuali (cfr. anche documento 5, paragrafo 1.6, di cui all'allegato A).

In base ai risultati della verifica dell'autenticità dei messaggi in arrivo, si può applicare un livello minimo di notifica di ricevimento:

i)	notifica positiva ACK;

ii)	notifica negativa NACK.

Per gestire le funzioni sopra descritte, l'interfaccia comune si avvale delle informazioni conservate nel repository centrale.

Per abbreviare i tempi di risposta, i soggetti partecipanti hanno facoltà di creare una versione «mirror» locale del repository centrale.

4.3.   Specifiche funzionali e tecniche delle interfacce

Di seguito sono descritte le specifiche funzionali e tecniche delle interfacce, definite alla luce dei requisiti essenziali di cui al capitolo 3.

4.3.1.   Interfacce con la STI Infrastruttura

Il sottosistema infrastruttura comprende i sistemi di gestione del traffico, di rintracciamento e di navigazione: impianti tecnici di elaborazione dati e di telecomunicazione previsti per il trasporto di passeggeri su lunga distanza e il trasporto di merci sulla rete al fine di garantire un esercizio sicuro e armonioso della rete e una gestione efficace del traffico.

I dati richiesti per finalità operative dal sottosistema Applicazioni telematiche per il trasporto merci sono ricavati dal contratto relativo alla traccia oraria ed eventualmente dalla banca dati aggiornata degli avvisi di restrizione, messa a disposizione dal GI. Non esiste quindi un'interfaccia diretta tra questa STI e la STI relativa all'infrastruttura.

4.3.2.   Interfacce con la STI Controllo/comando e segnalamento

L'unico collegamento con il controllo/comando e segnalamento si ha attraverso:

—	il contratto relativo alla traccia oraria, che nella descrizione del tratto di linea fornisce informazioni sulle apparecchiature di comando/controllo e segnalamento utilizzabili,

—	varie banche dati di riferimento relative al materiale rotabile, in cui devono essere conservati dati sulle apparecchiature di comando/controllo e segnalamento dei rotabili.

4.3.3.   Interfacce con il sottosistema Materiale rotabile

Il sottosistema Applicazioni telematiche per il trasporto merci identifica i dati tecnici e operativi che devono essere disponibili per il materiale rotabile.

La STI Materiale rotabile precisa le caratteristiche che devono possedere i carri. In caso di variazione delle caratteristiche di un carro, si deve procedere all'aggiornamento dei dati corrispondenti nelle banche dati di riferimento sul materiale rotabile nel quadro del normale processo di manutenzione della banca dati. Non esiste quindi un'interfaccia diretta tra questa STI e la STI per il materiale rotabile.

4.3.4.   Interfacce con la STI Esercizio e gestione del traffico

Il sottosistema Esercizio e gestione del traffico precisa le procedure e le associate apparecchiature che permettono di garantire un esercizio coerente dei diversi sottosistemi strutturali, sia durante il funzionamento normale che in caso di funzionamento irregolare, comprese la guida dei treni, la pianificazione e la gestione del traffico.

Il sottosistema Applicazioni telematiche per il trasporto merci contiene essenzialmente specifiche relative alle applicazioni per il trasporto merci, compreso il monitoraggio in tempo reale delle merci e dei treni e la gestione delle coincidenze con altri modi di trasporto.

Per garantire la coerenza tra le due STI, si applica la procedura seguente.

Quando verranno redatte e/o modificate le specifiche della STI Esercizio e gestione del traffico aventi attinenza con i requisiti della presente STI, dovrà essere consultato l'organismo responsabile della presente STI.

In occasione di eventuali modifiche delle specifiche della presente STI aventi attinenza con i requisiti operativi precisati nella STI Esercizio e gestione del traffico, dovrà essere consultato l'organismo responsabile della STI Esercizio e gestione del traffico.

4.4.   Norme operative

Alla luce dei requisiti essenziali di cui al capitolo 3, le norme operative specifiche del sottosistema oggetto della presente STI sono le seguenti.

4.4.1.   Qualità dei dati

Al fine di garantire la qualità dei dati, il mittente di un messaggio previsto dalla STI è responsabile della correttezza dei dati contenuti nel messaggio al momento del suo invio. Se nelle banche dati previste da questa STI sono disponibili dati sorgente utilizzabili per garantire la qualità dei dati, i dati contenuti in tali banche dati devono essere usati per tale scopo.

Se nelle banche dati previste da questa STI non sono disponibili dati sorgente utilizzabili per garantire la qualità dei dati, il mittente del messaggio deve effettuare i controlli necessari per garantire la qualità dei dati utilizzando le proprie risorse.

La garanzia di qualità dei dati comprende il confronto con i dati contenuti nelle banche dati previste da questa STI e descritte in precedenza nonché, se del caso, controlli logici diretti ad accertare la tempestività e la continuità dei dati e dei messaggi.

I dati sono di qualità elevata se sono adatti agli scopi a cui sono destinati, e dunque se:

—	sono privi di errori, quindi accessibili, accurati, tempestivi, completi, congruenti con altre fonti, ecc.,

—	possiedono le caratteristiche desiderate, quindi rilevanza, completezza, livello di dettaglio appropriato, facilità di lettura, facilità di interpretazione, ecc.

La qualità dei dati è determinata essenzialmente dalle caratteristiche seguenti:

—	accuratezza,

—	completezza,

—	congruenza,

—	tempestività.

Accuratezza

L'acquisizione delle informazioni (dati) richieste deve essere effettuata nel modo più economico. Ciò è possibile soltanto se i dati primari, determinanti ai fini dell'inoltro di un carico di merce, carro o container, vengono registrati una sola volta per tutto il trasporto, sempreché ciò sia possibile. È opportuno quindi che i dati primari siano inseriti nel sistema in un punto il più possibile vicino alla loro origine, ad es. dopo il ricevimento della lettera di vettura redatta per la richiesta di offerte relative al trasporto di un carro o di un carico, in modo da garantirne la piena integrazione in tutte le operazioni successive di elaborazione.

Completezza

Prima di inviare un messaggio, è necessario verificarne la completezza e la sintassi per mezzo dei metadati. In questo modo si evita anche di appesantire la rete con traffico inutile.

Il controllo della completezza per mezzo dei metadati deve essere eseguito anche su tutti i messaggi in arrivo.

Congruenza

Per garantire la congruenza, devono essere applicati principi aziendali. È opportuno evitare di inserire più volte gli stessi dati e identificare chiaramente il proprietario dei dati.

Le modalità di applicazione di questi principi dipendono dalla complessità dei principi stessi. Per i principi più semplici possono bastare i vincoli e i trigger delle banche dati. Nel caso di principi più complessi che richiedono dati provenienti da diverse tabelle, devono essere applicate procedure di validazione che verifichino la congruenza della versione dei dati prima che vengano generati i dati dell'interfaccia e che divenga operativa la nuova versione dei dati. Per i dati trasferiti deve essere garantita la validazione rispetto ai principi aziendali definiti.

Tempestività

La tempestività, intesa come capacità di fornire informazioni esattamente nel momento richiesto, è una caratteristica importante. La tempestività non rappresenta un problema quando la memorizzazione dei dati o l'invio di un messaggio vengono effettuati direttamente dal sistema IT in conseguenza di un evento, a patto naturalmente che il sistema sia ben progettato in base alle esigenze dei processi aziendali. Nella maggior parte dei casi, però, l'invio di un messaggio viene avviato da un operatore o quantomeno si basa sul completamento dei dati da parte di un operatore (ad esempio l'invio della composizione del treno o l'aggiornamento dei dati relativi al treno o al carro). Per garantire la tempestività, l'aggiornamento dei dati deve essere effettuato non appena possibile, anche per far sì che i messaggi inviati automaticamente dal sistema contengano dati effettivi.

In genere devono essere soddisfatti i requisiti seguenti:

Il tempo di risposta alle richieste di informazioni deve essere inferiore a 5 minuti. Tutti gli aggiornamenti e gli scambi di dati devono essere effettuati non appena possibile. Il tempo di reazione e trasmissione del sistema per l'aggiornamento dovrebbe essere inferiore a 1 minuto.

Misure della qualità dei dati

Per la completezza (percentuale di campi contenenti valori) dei dati obbligatori e per la congruenza dei dati (percentuale di valori concordanti in tabelle/file/record), deve essere raggiunta la percentuale del 100 %.

Per la tempestività dei dati (percentuale di dati disponibili entro un tempo soglia specificato), deve essere raggiunta la percentuale del 98 %. Dato che la presente STI non precisa i valori soglia, tali valori devono essere indicati nei contratti tra i soggetti interessati.

L'accuratezza richiesta (percentuale di valori memorizzati che coincidono con i valori effettivi) deve essere superiore al 90 %. Il valore esatto e i criteri da applicare devono essere indicati nei contratti tra i soggetti interessati.

4.4.2.   Gestione del repository centrale

Le funzioni del repository centrale (il deposito centrale dei dati), sono definite al paragrafo 4.2.14.6 (Repository centrale). Per garantire la qualità dei dati, l'organismo che gestisce il repository centrale dovrebbe essere responsabile dell'aggiornamento e della qualità dei metadati e della directory, nonché della gestione del controllo degli accessi (chiavi pubbliche). Per quanto attiene alla qualità dei metadati, la completezza, la congruenza, la tempestività e l'accuratezza devono raggiungere la percentuale del 100 %.

4.5.   Norme di manutenzione

Di seguito sono descritte le norme di manutenzione specifiche per il sottosistema oggetto di questa STI, definite alla luce dei requisiti essenziali di cui al capitolo 3.

La qualità del servizio di trasporto deve essere garantita anche in caso di malfunzionamento totale o parziale delle apparecchiature di elaborazione dati. È quindi consigliabile duplicare i sistemi o computer, avendo cura di scegliere soluzioni con un'affidabilità particolarmente elevata e in grado di garantire un funzionamento ininterrotto durante le operazioni di manutenzione.

Gli aspetti legati alla manutenzione delle varie banche dati sono riportati nel paragrafo 4.2.12.3 (Altri requisiti delle banche dati) ai punti 10 e 21.

4.6.   Qualifiche professionali

Di seguito sono descritte le qualifiche professionali del personale necessario per l'esercizio e la manutenzione del sottosistema e per l'applicazione della STI.

L'applicazione di questa STI non richiede l'utilizzo di un nuovo sistema hardware e software o l'impiego di nuovo personale ma soltanto variazioni, adeguamenti o ampliamenti funzionali dell'esercizio a cui già provvede il personale esistente. Non sono previsti quindi altri requisiti in aggiunta alle norme nazionali ed europee vigenti in materia di qualifiche professionali.

La formazione supplementare del personale, nei casi in cui è necessaria, non deve limitarsi alle indicazioni su come far funzionare le apparecchiature. Ogni persona deve conoscere e capire la funzione specifica attribuitale nel processo globale di trasporto. Il personale deve essere consapevole in particolare della necessità di mantenere uno standard elevato di efficienza nello svolgimento delle proprie mansioni, perché questo elemento è decisivo ai fini dell'affidabilità delle informazioni per le quali è prevista una successiva elaborazione.

Le qualifiche professionali necessarie per la composizione e la circolazione dei treni sono definite nella STI Esercizio e gestione del traffico.

4.7.   Requisiti di igiene e sicurezza sul lavoro

I requisiti di igiene e sicurezza sul lavoro relativi al personale necessario per l'esercizio e la manutenzione del sottosistema in oggetto (il cui campo d'applicazione è precisato al paragrafo 1.1) e per l'applicazione della STI sono indicati di seguito.

Non sono previsti altri requisiti in aggiunta alle norme nazionali ed europee vigenti in materia di igiene e sicurezza sul lavoro.

4.8.   Registri dell'infrastruttura e del materiale rotabile

A norma dell'articolo 24, paragrafo 1, della direttiva 2001/16/CE, «gli Stati membri provvedono affinché siano pubblicati e aggiornati annualmente registri dell'infrastruttura e del materiale rotabile che presentino, per ciascun sottosistema o parte di sottosistema interessati, le caratteristiche principali e la loro concordanza con le caratteristiche prescritte dalle STI applicabili. A tal fine, ciascuna STI indica con precisione le informazioni che debbono figurare nei registri dell'infrastruttura e del materiale rotabile.»

La scadenza annuale fissata per l'aggiornamento e la pubblicazione di questi registri li rende inutilizzabili ai fini del sottosistema Applicazioni telematiche per il trasporto merci; pertanto, questa STI non contiene alcuna indicazione riguardo alle informazioni da inserire in questi registri.

5.   COMPONENTI DI INTEROPERABILITÀ

5.1.   Definizione

Ai sensi dell'articolo 2, lettera d), della direttiva 2001/16/CE:

per componenti di interoperabilità si intende «qualsiasi componente elementare, gruppo di componenti, sottoinsieme o insieme completo di materiali incorporati o destinati ad essere incorporati in un sottosistema da cui dipende direttamente o indirettamente l'interoperabilità del sistema ferroviario transeuropeo convenzionale. Il concetto di componente abbraccia i beni materiali e immateriali, quali il software.»

5.2.   Elenco dei componenti

I componenti di interoperabilità sono oggetto di specifiche disposizioni della direttiva 2001/16/CE.

Per il sottosistema Applicazioni telematiche per il trasporto merci non è definito alcun componente di interoperabilità.

Per rispettare i requisiti di questa STI, sono sufficienti apparecchiature IT standard e non sono previsti aspetti specifici per l'interoperabilità in ambiente ferroviario. Questo vale per i componenti hardware e per i software standard utilizzati, quali ad esempio il sistema operativo e i database. Il software applicativo è implementato da ciascun utente a livello individuale e può essere adattato e migliorato in base alle funzionalità effettive e alle esigenze specifiche. L'«architettura per l'integrazione delle applicazioni» proposta prevede che le applicazioni possano non avere lo stesso modello di informazioni interno. Per «integrazione delle applicazioni» si intende il processo che permette di far funzionare insieme sistemi applicativi progettati in modo indipendente.

5.3.   Prestazioni e specifiche dei componenti

Non rilevante ai fini della STI Applicazioni telematiche per il trasporto merci (cfr. paragrafo 5.2).

6.   VALUTAZIONE DELLA CONFORMITÀ E/O IDONEITÀ ALL'USO DEI COMPONENTI E VERIFICA DEL SOTTOSISTEMA

6.1.   Componenti di interoperabilità

6.1.1.   Procedure di valutazione

La procedura di valutazione della conformità o idoneità all'uso dei componenti di interoperabilità deve basarsi su specifiche europee o su specifiche approvate ai sensi della direttiva 2001/16/CE.

Nel caso dell'idoneità all'uso, tali specifiche devono indicare tutti i parametri da misurare, monitorare o osservare, e descrivere i relativi metodi di prova e procedimenti di misura, sia per le simulazioni al banco che per le prove in ambiente ferroviario reale.

Procedure per la valutazione della conformità e/o dell'idoneità all'uso:

elenco delle specifiche, descrizione dei metodi di prova.

Non rilevante ai fini della STI Applicazioni telematiche per il trasporto merci.

6.1.2.   Modulo

La procedura viene effettuata, su richiesta del fabbricante o del suo mandatario stabilito nella Comunità, da un organismo notificato conformemente alle disposizioni dei moduli pertinenti della decisione 93/465/CEE indicati, modificati e integrati nell'allegato della presente STI.

È opportuno che i moduli siano combinati e utilizzati in maniera selettiva in funzione del componente specifico.

Non rilevante ai fini della STI Applicazioni telematiche per il trasporto merci.

6.2.   Sottosistema Applicazioni telematiche per il trasporto merci

Su richiesta dell'ente aggiudicatore o del suo mandatario stabilito nella Comunità, l'organismo notificato effettua la verifica CE in conformità dell'allegato VI della direttiva 2001/16/CE.

Ai sensi dell'allegato II della direttiva 2001/16/CE, i sottosistemi si suddividono in strutturali e operativi.

La valutazione di conformità è obbligatoria per le STI relative a sottosistemi strutturali. Il sottosistema Applicazioni telematiche per il trasporto merci è di tipo operativo e la presente STI non definisce alcun modulo per la valutazione della conformità.

Tuttavia, il repository centrale e l'interfaccia comune nel nodo di ciascun soggetto partecipante sono la «spina dorsale» dell'integrazione delle applicazioni. Il modello per lo scambio di informazioni è contenuto nel repository centralizzato per l'integrazione delle applicazioni, che riunisce in un unico luogo fisico i metadati sull'interfaccia. I metadati contengono informazioni sul contenuto delle comunicazioni (cosa c'è nei dati che si stanno inviando), sull'identità dei referenti nelle organizzazioni dei mittenti e dei destinatari, e sulle procedure aziendali a livello applicativo per lo svolgimento del processo di interazione.

Si evidenziano i punti seguenti.

—	Il repository centrale contiene la directory («elenco telefonico») di tutti i soggetti che prendono parte allo scambio di messaggi. Tale directory deve presentare in ogni momento la situazione effettiva. L'inserimento di dati errati diventa subito evidente. Non occorre una procedura di valutazione.

—	Il repository centrale contiene anche dati sugli organismi di certificazione (PKI Open CA). Tali dati sono sostanzialmente l'espressione fisica di un atto amministrativo. L'inserimento di dati errati diventa subito evidente. Non occorre una procedura di valutazione.

—

Il repository centrale contiene i metadati relativi ai messaggi (secondo quanto indicato nel documento 1 di cui all'allegato A), che rappresentano la base per lo scambio di messaggi in un ambiente informativo eterogeneo. I metadati devono essere gestiti e aggiornati nel repository centrale. Ogni eventuale incompatibilità nella struttura o nel contenuto dei messaggi utilizzati per l'invio o la ricezione di dati viene subito riconosciuta e il trasferimento viene rifiutato. Non occorre una procedura di valutazione.

—

Per ridurre i tempi di risposta e il carico a cui è sottoposto il repository, l'interfaccia comune nel nodo di ciascun soggetto contiene in genere un'immagine speculare («mirror») del repository centrale. Deve essere sempre garantita la concordanza tra la versione dei dati contenuta nel repository centrale e quella contenuta nell'interfaccia comune. L'aggiornamento dei dati, quindi, deve essere effettuato a livello centrale e le nuove versioni devono essere scaricate dal repository centrale. Non occorre una procedura di valutazione.

7.   APPLICAZIONE

7.1.   Modalità di applicazione della presente STI

7.1.1.   Introduzione

La presente STI si propone di fornire un supporto informativo per il processo commerciale di trasporto merci per ferrovia; in quest'ottica, può contribuire a migliorare sensibilmente la qualità dei servizi di trasporto. Per questo motivo, la sua applicazione è indipendente dai concetti di infrastrutture o rotabili nuovi/ristrutturati o già esistenti, richiamati invece in altre STI previste dalla direttiva 2001/16/CE.

Questa STI sarà applicata capillarmente e perciò avrà ripercussioni profonde sui processi operativi e commerciali di tutta l'industria ferroviaria europea. D'altra parte, la crescita continua del trasporto merci internazionale impone l'adozione di una prospettiva europea nella gestione delle informazioni. Questi elementi, sommati, rendono opportuna l'elaborazione di un piano transeuropeo coerente per l'applicazione della STI. Tale piano dovrebbe indicare sia i traguardi da raggiungere nell'applicazione della STI, sia i modi e i tempi con cui dovrà attuarsi la migrazione dagli attuali sistemi informativi frammentati a un'autostrada informativa europea generale in grado di offrire valore aggiunto a tutti i soggetti interessati nel settore del trasporto ferroviario: gestori dell'infrastruttura, imprese ferroviarie, spedizionieri e clienti.

In questa prospettiva si impone il concetto di Piano strategico europeo di attuazione (PSEA). Lo PSEA, descritto schematicamente nel paragrafo successivo, definisce il sistema obiettivo da realizzare per dare applicazione alla STI e ne precisa il piano di introduzione.

7.1.2.   Piano strategico europeo di attuazione (PSEA)

7.1.2.1.   Obiettivi dello PSEA

Il Piano strategico europeo di attuazione (PSEA) ha tre obiettivi:

1)	definire un quadro di riferimento per l'applicazione della STI Applicazioni telematiche per il trasporto merci (ATTM) nell'industria ferroviaria europea;

2)	precisare le caratteristiche di tale quadro dal punto di vista della fattibilità tecnica ed economica;

3)	definire un piano di attuazione delle attività ritenute necessarie per l'applicazione di tale quadro.

Oltre a definire un piano di attuazione della STI ATTM che assicuri la visibilità di tutto il processo di attuazione, lo PSEA dovrebbe descrivere opportuni criteri utilizzabili dai vari soggetti interessati — gestori dell'infrastruttura, imprese ferroviarie, spedizionieri e clienti — per seguire l'avanzamento dei lavori e tutelare i propri interessi. Questo aspetto si ricollega in particolare agli investimenti che gestori dell'infrastruttura e imprese ferroviarie devono effettuare per aggiornare e integrare i sistemi IT legacy (ereditati dal passato), nonché alla capacità dei sistemi basati sulla STI ATTM di rispondere in modo efficiente all'evolversi delle esigenze informative espresse tanto dagli spedizionieri quanto dai clienti.

In quest'ottica, lo PSEA dovrebbe essere in definitiva uno strumento che permette a tutta l'industria ferroviaria europea di concentrarsi sullo sviluppo di un sistema informativo paneuropeo promuovendo sinergie, evitando frammentazioni e concentrando le risorse, disponibili in quantità limitata, sugli aspetti prioritari che meglio rispondono agli obiettivi fondamentali di qualità dei servizi di trasporto.

7.1.2.2.   I requisiti relativi allo PSEA

L'elaborazione dello PSEA richiederà un'analisi sistematica degli aspetti tecnici, operativi, economici e istituzionali collegati al processo di attuazione della STI ATTM. Tali aspetti comprendono in particolare:

1)	l'inventario delle applicazioni IT legacy eventualmente utilizzabili per costruire un sistema paneuropeo in grado di applicare le prescrizioni della STI ATTM (di seguito «sistema ATTM»);

2)	la definizione dei dati funzionali e associati e dei requisiti relativi alle prestazioni da rispettare nell'attuazione della STI ATTM;

3)

le descrizione schematica dell'architettura del sistema ATTM. Tale descrizione si basa sull'analisi delle configurazioni del sistema potenzialmente in grado potenzialmente di integrare i componenti IT legacy e al contempo di garantire le funzionalità e le prestazioni richieste — ad es. architetture client-server centralizzate o distribuite, architetture basate su agenti;

4)	la definizione dei requisiti tecnici e di interfaccia per il sistema ATTM ed i potenziali sottosistemi/sistemi client;

5)

l'elaborazione di un piano generale di sviluppo del sistema ATTM, dalla definizione concettuale alla consegna. Tale piano dovrebbe indicare gli orientamenti per il processo e la pianificazione della potenziale integrazione dei componenti legacy nonché una valutazione dei rischi delle fasi cruciali di tale piano. Esso dovrebbe inoltre indicare l'evoluzione in atto e prevista dei componenti legacy;

6)	l'identificazione delle opportune strutture amministrative che dovranno sostenere lo sviluppo del sistema ATTM e il suo funzionamento nell'arco della sua vita utile;

7)	una valutazione dei costi totali nel ciclo di vita associati all'introduzione e all'utilizzo del sistema ATTM e un successivo piano di investimenti.

L'analisi non dovrebbe seguire un percorso sequenziale ma svilupparsi in modo iterativo nell'obiettivo di individuare la strategia ottimale di introduzione del sistema. Il ciclo di studio dovrebbe sfociare in particolare nella definizione dei seguenti elementi:

—	una serie completa di specifiche funzionali, tecniche, relative alle prestazioni e al sistema da utilizzare nell'appalto per il sistema ATTM,

—	un piano di introduzione, dalla definizione concettuale alla consegna, comprensivo di piani dettagliati per tutte le fasi del progetto e le singole attività rilevanti che concorrono al conseguimento degli obiettivi finali,

—	la definizione della struttura, dei metodi e delle procedure amministrative (7) da utilizzare per lo sviluppo, la validazione e la gestione del sistema,

—	un piano di investimenti e una successiva strategia di ingegneria finanziaria che ne permetta la realizzazione.

7.1.3.   Modalità di applicazione

Le modalità di attuazione della presente STI sono oggetto delle prescrizioni del piano strategico europeo di attuazione (PSEA) illustrato sommariamente in precedenza.

L'elaborazione dello PSEA è soggetta alle seguenti prescrizioni:

—	le imprese ferroviarie e i gestori dell'infrastruttura mettono a disposizione le informazioni funzionali e tecniche relative alle singole applicazioni telematiche esistenti per il trasporto merci (8);

—

gli organismi rappresentativi del settore ferroviario che agiscono a livello europeo, definiti nell'articolo 3, paragrafo 2, del regolamento (CE) n. 881/2004, definiscono un piano strategico europeo di attuazione avente le caratteristiche indicate schematicamente nel paragrafo precedente. Essi trasmettono questo piano strategico agli Stati membri e alla Commissione entro un anno dalla data di pubblicazione del regolamento citato. In mancanza di progressi significativi entro il termine indicato, la Commissione si assume il compito di proporre progetti di testi legislativi per l'applicazione di questa STI;

—

una volta completato il piano strategico, tutte le attività collegate all'attuazione del sottosistema Applicazioni telematiche per il trasporto merci devono trovare legittimazione nel piano di attuazione. Qualsiasi proposta di non conformità avanzata da un'IF o da un GI deve essere motivata nel fascicolo di applicazione presentato allo Stato membro, all'Agenzia ferroviaria europea e alla CE.

7.2.   Strategia di migrazione

Devono essere elaborate strategie di migrazione da applicare nel periodo di transizione dal quadro attuale, caratterizzato dalla presenza di sistemi informativi diversi, alla piena applicazione della STI secondo quanto disposto dallo PSEA.

Per facilitare la migrazione sono stati elaborati i concetti di gestione delle informazioni contenuti in questa STI. Tali concetti permettono una costruzione progressiva del sistema ATTM paneuropeo, in particolare attraverso funzioni quali le comunicazioni peer-to-peer basate ad es. sul concetto di repository di dati aggregati (cioè contenenti metadati sui messaggi, sulla directory e sugli organismi di certificazione).

Di seguito è riportato un esempio che illustra come potrebbe realizzarsi in pratica lo scambio di informazioni tra un'IF e un GI. L'esempio mostra soltanto, nelle varie fasi, i rapporti di dipendenza delle comunicazioni logiche tra sistemi senza dar conto delle singole esigenze di migrazione che potrebbero essere associate ai singoli sistemi. Tali esigenze dovranno essere prese in debita considerazione in fase di elaborazione dello PSEA.

Fase 1: l'architettura generale, descritta al paragrafo 4.2.14.1 (Architettura generale), prevede un «repository centrale» gestito da un soggetto neutro indipendente. Nella sede di ciascun soggetto partecipante alla rete di comunicazione deve essere realizzato un livello di interfaccia, che può includere un message broker, in modo da garantire l'interoperabilità; tale interfaccia può essere realizzata a livello centrale o individuale. Per la parte «Reti e comunicazioni» si tratta degli unici requisiti operativi per l'interoperabilità. Essi rappresentano anche il presupposto essenziale per poter avviare lo scambio di dati su scala europea. La loro applicazione rappresenta quindi una condizione preliminare che deve essere soddisfatta prima di poter introdurre qualsiasi altra funzione.

Al termine di questa fase può già realizzarsi la trasmissione elettronica dei documenti (4.2.13: Trasmissione elettronica dei documenti) a prescindere dalla sequenza logica delle altre fasi.

Caratteristiche disponibili dopo questa fase per
GI	IF
Poste le basi per lo scambio di informazioni. Vantaggi:   Possibilità di effettuare la trasmissione elettronica dei documenti nell’ambiente finale.   Possibilità di effettuare prove delle varie fasi successive in ambiente reale.

Fase 2: contemporaneamente o subito dopo la fase 1, devono essere disponibili le banche dati di riferimento sul materiale rotabile e la banca dati operativa dei carri e delle unità intermodali (paragrafi 4.2.11.3: Banche dati di riferimento sul materiale rotabile e 4.2.12.2: Altre banche dati). Se nelle banche dati non sono già presenti tutti i dati, deve essere quantomeno possibile inserire manualmente nella banca dati operativa dei carri e delle unità intermodali, per ciascun carro in composizione a un treno in marcia, i dati necessari per il trasporto ferroviario, indicati nel documento 2 di cui all'allegato A.

Caratteristiche disponibili dopo questa fase per
GI	IF
Possibilità di accedere alle informazioni fondamentali contenute nella banca dati operativa dei carri e delle unità intermodali e nelle banche dati di riferimento sul materiale rotabile. Possibilità di provvedere all’aggiornamento manuale dei dati di interesse. Vantaggi:   Attivazione del supporto IT per le richieste di traccia oraria e la composizione dei treni.   Possibilità per soggetti terzi, ad es. gestori di parchi rotabili, di accedere agevolmente ai dati sul materiale rotabile.

Fase 3: per consentire l'accesso esterno alle varie banche dati, contemporaneamente o subito dopo la fase 2 deve essere creata e applicata l'interfaccia comune.

Caratteristiche disponibili dopo questa fase per
GI	IF
Predisposizione di una banca dati per le informazioni relative a tracce/treni. Possibilità di cominciare ad inserire manualmente i dati. Disponibilità di una connessione on-line con i sistemi esistenti dei GI per l’inserimento e l’aggiornamento automatici dei dati. Vantaggi:   Possibilità di registrare in forma definitiva i dati dei messaggi in arrivo.	Predisposizione delle banche dati per i dati relativi ai movimenti di carri/unità intermodali e al carico (peso, merci pericolose), nonché degli archivi di riferimento necessari. Possibilità, da questo punto in avanti, di inserire in modo manuale o già in modo automatico, attraverso la connessione interna dell’IF ai sistemi esistenti per la registrazione delle lettere di vettura e della composizione del treno, i dati di interesse ricavati dalle lettere di vettura (richiesta di carri) consegnate e/o dalla composizione dei treni. Possibilità di controllare i dati dei carri facendo riferimento alle banche dati di riferimento sul materiale rotabile e di valutare i dati dei treni in relazione ai dati dell’infrastruttura. Vantaggi:   Supporto alla creazione della composizione del treno.   Possibilità di memorizzare come versione finale i dati dei messaggi in entrata.

Per le fasi successive è importante notare che l'architettura proposta permette un'operatività graduale delle varie funzioni per soddisfare i requisiti del sottosistema Applicazioni telematiche per il trasporto merci. Attraverso il repository centrale (metadati sui messaggi, directory e organismo di certificazione), è possibile attivare lo scambio di dati tra due soggetti specifici, in funzione del tipo di messaggio.

Fase 4: i messaggi di richiesta di traccia possono essere implementati indipendentemente dalle fasi successive, ma per la fase 6 è necessario che la traccia sia già identificata da un numero di traccia.

Caratteristiche disponibili dopo questa fase per
GI	IF
Inserimento automatico dei dati nella banca dati per la registrazione delle informazioni su tracce/treni. Supporto telematico alla definizione della traccia insieme alle banche dati degli avvisi di restrizione dell’infrastruttura. Vantaggi:   Maggior rapidità di reazione alle richieste di tracce orarie, uso delle tracce più orientato alla domanda, maggiore affidabilità dei dati sulle caratteristiche delle tracce (situazione corrente nelle banche dati degli avvisi di restrizione dell’infrastruttura), uso più efficiente dell’infrastruttura.	Possibilità di inviare richieste di traccia in gestione operativa. Vantaggi:   Possibilità di definire richieste di traccia più orientate alla domanda. Maggior rapidità di reazione alle richieste di traccia da parte dei GI. Maggiore affidabilità dei dati sulle caratteristiche delle tracce orarie. Riduzione dei tempi di rotazione dei carri.

Fase 5: i dati delle richieste di carri contengono informazioni essenziali per la composizione del treno, perciò questi messaggi devono diventare operativi prima della fase 6.

Caratteristiche disponibili dopo questa fase per
GI	IF
Nessuna caratteristica aggiuntiva.	Acquisizione automatica dei dati della lettera di vettura nella registrazione dei dati della fase 3. Predisposizione e invio automatici di richieste di carri alle IF cooperanti. Vantaggi:   Distribuzione più veloce delle richieste di carri, tempi di manipolazione più brevi ai punti di interscambio.   Supporto per l’applicazione di contratti internazionali di acquisto/vendita.

Fase 6: nella fase successiva diventano operativi i messaggi di preparazione del treno; il messaggio sulla composizione del treno è il più importante ed è il primo da implementare.

Caratteristiche disponibili dopo questa fase per
GI	IF
Ricevimento anticipato della composizione del treno. Maggiore affidabilità dei dati. Indicazione chiara dell’orario di partenza per l’uso della traccia oraria. Aggiornamento automatico della banca dati per la registrazione delle informazioni su tracce/treni. Vantaggi:   Ottimizzazione dell’uso delle tracce, responsabilità chiare all’orario di partenza.	Invio della composizione del treno generata in modo prevalentemente automatico, elevata affidabilità dei dati, aggiornamento automatico nella registrazione dei dati della fase 3. Vantaggi:   Responsabilità chiara per il servizio del GI all’orario di partenza, orario di partenza affidabile per carri/spedizioni.   Contributo alla riduzione delle spese e dei costi grazie ai riduzione dei dati da acquisire alle frontiere.   Contributo alla riduzione dei tempi di spedizione grazie alla presa in carico garantita dei treni da parte di IF e GI.   Contributo alla riduzione dei rischi durante la presa in carico dei carri.

Fase 7: al più tardi prima della fase 8 devono essere implementate a livello di IF le funzioni relative all'avviso di messa a disposizione del carro e di partenza, arrivo del carro al piazzale, partenza del carro dal piazzale, avviso di arrivo del carro e notifica/conferma di consegna del carro nonché la funzione relativa ai piani di inoltro.

Caratteristiche disponibili dopo questa fase per
GI	IF
Nessuna caratteristica aggiuntiva	Possibilità di avere un supporto IT per la creazione dei piani di inoltro a livello di carro e unità intermodale. Possibilità di utilizzare il sistema per calcolare, inviare e ricevere messaggi sui movimenti dei carri e delle unità intermodali. Vantaggi:   Prima fase per la localizzazione e il rintracciamento di carri e spedizioni a livello internazionale.

Fase 8: per la fase successiva dovrebbero essere implementati i messaggi Treno in marcia e Previsione di marcia del treno. Con il messaggio Previsione di marcia del treno può essere inviato l'orario previsto di arrivo del treno (TETA ed ETH), su cui si basa il calcolo degli ETI relativi al carro/spedizione e dell'ETA. In questa fase è prevista anche l'implementazione della richiesta di informazioni/risposta su Treno in marcia e Previsione di marcia del treno.

Caratteristiche disponibili dopo questa fase per
GI	IF
Treno in marcia e Previsione di marcia del treno in tempo reale inviati ai GI vicini e alle IF. Vantaggi:   Possibilità di rendere più efficiente e affidabile la pianificazione, per un uso efficiente delle tracce.   Riduzione delle soste alle frontiere, supporto a un uso delle tracce orientato alla domanda.	Disponibilità della posizione e dell’orario stimato del treno, utilizzabili per il calcolo dell’ETI/ETA del carro/spedizione. Vantaggi:   Strumento che permette di rispondere al desiderio del cliente di essere informato in caso di problemi nel trasporto.   Insieme al completamento della fase 4 contributo alla riduzione delle spese e dei costi attraverso un uso delle tracce orientato alla domanda.   Possibilità di rendere più efficiente e affidabile la pianificazione.   Contributo alla riduzione dei tempi di spedizione attraverso la riduzione delle soste alle frontiere.   Contributo alla riduzione dei rischi durante la presa in carico dei treni.

Fase 9: le comunicazioni di interscambio (paragrafo 4.2.9: Comunicazioni di interscambio) e la funzionalità di cui al paragrafo 4.2.7 (ETI/ETA della spedizione) dovrebbero essere implementate contemporaneamente o subito dopo la fase 8. Ha valore in particolare per le IF.

Caratteristiche disponibili dopo questa fase per
GI	IF
Possibilità di conoscere la posizione di un carro nell’infrastruttura del GI, nonché di sapere qual è l’IF responsabile, anche se il carro non è in composizione a un treno. Vantaggi:   Possibilità di conoscere la posizione di un carro e di sapere qual è il soggetto responsabile in un piazzale.	Calcolo dell’ETI e dell’ETA in base ai valori del TETA, aggiornamento automatico dei dati sui movimenti nella banca dati operativa dei carri e delle unità intermodali. Piena applicazione della gestione internazionale dei carri vuoti. Completata la pianificazione internazionale dei viaggi. Vantaggi:   Localizzazione e rintracciamento a livello internazionale.   Riduzione dei tempi di rotazione dei carri.   Supporto per la gestione internazionale dei carri vuoti.   Supporto per le spedizioni all’estero e la prenotazione dei servizi offerti.   Contributo al miglioramento della qualità dei trasporti internazionali.   Supporto per la pianificazione internazionale dei viaggi.

Fase 10: l'implementazione della funzionalità Informazioni concernenti la perturbazione del servizio ricade nella fase 10, così come l'implementazione delle richieste/risposte sul ritardo dei treni, sui codici di identificazione dei treni e sui treni alle località di segnalazione. Con le informazioni concernenti la perturbazione del servizio potrebbe diventare operativo il messaggio sugli imprevisti del carro a livello di IF (paragrafi 4.2.8.6: Imprevisti del carro e 4.2.8.7: Imprevisti del carro – Richiesta di nuovo ETI/ETA).

Caratteristiche disponibili dopo questa fase per
GI	IF
Gestione delle perturbazioni del servizio e distribuzione di informazioni rilevanti per le IF. Vantaggi:   Miglioramento della qualità del servizio.	Gestione degli scostamenti e richieste di informazioni rilevanti. Vantaggi:   Localizzazione e rintracciamento delle spedizioni internazionali.   Riduzione dei tempi di rotazione dei carri.

Fase 11: dopo una fase di consolidamento, potrebbe diventare operativa la valutazione dei dati trasmessi e registrati per il miglioramento della qualità.

Caratteristiche disponibili dopo questa fase per
GI	IF
Disponibilità di una banca dati statistica completa. Vantaggi:   Disponibilità di dati in ingresso per il miglioramento della qualità del servizio di trasporto.

7.3.   Gestione del cambiamento

7.3.1.   Introduzione

Il cambiamento è un aspetto che interessa tutti i sistemi computerizzati utilizzati in condizioni reali. I motivi all'origine del cambiamento sono l'emergere di nuovi requisiti o la variazione dei requisiti esistenti, attuata allo scopo di ovviare a errori segnalati in fase operativa o migliorare le prestazioni o altre caratteristiche non funzionali.

Il cambiamento, però, va gestito, in quanto può avere ripercussioni sulla continuità del servizio e deve garantire la compatibilità con i sistemi esistenti in modo da ridurre al minimo l'aggravio di costi e tempo associato all'utilizzo dei componenti IT con funzionalità ATTM già in uso (componenti IT legacy). Per questo, assume un'importanza cruciale la definizione di una strategia chiara per l'attuazione e la gestione del cambiamento applicato ai componenti IT legacy, nell'intento di evitare perturbazioni nell'esercizio ferroviario senza rendere inefficaci gli obiettivi sottesi di garanzia dell'interoperabilità e continuità del servizio. La definizione di una siffatta strategia si basa su due importanti elementi:

—

la creazione di un modello di gestione della configurazione che definisca le norme e le procedure da attuare per gestire l'evoluzione del sistema. Tale modello dovrebbe comprendere le procedure da seguire per registrare e dar seguito ai cambiamenti proposti, per metterli in relazione ai componenti del sistema e per tenere traccia delle varie release (versioni successive) del sistema;

—	una politica per il rilascio delle baseline (configurazioni di riferimento).

7.3.2.   Baseline

Per poter introdurre e implementare in modo realistico un sistema, è indispensabile che tale sistema sia stabile. La stabilità è un'esigenza che accomuna tutti i soggetti coinvolti:

—	i gestori dell'infrastruttura e gli operatori ferroviari, che si troveranno a dover gestire varie versioni dei sistemi con funzionalità ATTM,

—	l'industria, che ha bisogno di tempo per la definizione delle specifiche, lo sviluppo e la dimostrazione della non interruzione dell'interoperabilità.

In sostanza, una baseline o configurazione di riferimento è un nucleo di partenza stabile definito in termini di funzionalità di sistema, prestazioni e altre caratteristiche non funzionali (ad es. RAM) (9). L'esperienza acquisita in passato con questo tipo di sistemi dimostra però che per ottenere una baseline stabile e implementabile sono necessarie varie release (10) successive. Si tratta di un processo a cascata che si può raffigurare nel modo seguente:

Per la presenza di anelli di retroazione, questo processo è caratterizzato da una stretta interconnessione. Da ciò deriva l'impossibilità di mettere in parallelo più processi: si creerebbero infatti instabilità, confusione e intralci operativi. Ne consegue che le baseline devono essere gestite in serie e non in parallelo, come illustra il diagramma che segue:

7.3.3.   Rilascio delle baseline

In base all'esperienza acquisita, l'intervallo di tempo intercorrente tra il rilascio di due baseline successive può essere stimato in circa quattro o cinque anni.

In teoria, una nuova baseline dovrebbe comportare variazioni significative della funzionalità o delle prestazioni del sistema, ad esempio:

—	l'inclusione dell'insieme delle funzioni nazionali correnti, allorché sia possibile una loro generalizzazione, nel nucleo interoperabile,

—	altri servizi futuri a valore aggiunto.

Ciascuna baseline deve includere le funzionalità della configurazione precedente. Per eliminare gli errori o le carenze in materia di sicurezza dei dati, è opportuno ricorrere a una nuova release della baseline. Le nuove release di una stessa baseline devono essere compatibili con le release precedenti, tranne nel caso in cui problemi legati alla sicurezza dei dati lo impediscano.

Visto che in ogni baseline vengono aggiunte nuove funzionalità, non può esserci compatibilità con le configurazioni precedenti. Tuttavia, per favorire la migrazione le varie baseline dovrebbero incorporare, nei limiti consentiti sul piano tecnico, un nocciolo comune di funzionalità per le quali dovrebbe essere garantita la compatibilità con le configurazioni precedenti. Tale nocciolo comune dovrebbe assicurare, con prestazioni accettabili, un livello minimo di interoperabilità dei servizi dati.

7.3.4.   Introduzione delle nuove baseline

I gestori dell'infrastruttura e gli operatori ferroviari non saranno mai in grado di passare a una nuova baseline da un giorno all'altro. Per questo, insieme ad ogni baseline deve essere elaborata un'opportuna strategia di migrazione che permetta di affrontare problemi, quali la coesistenza di sistemi ATTM conformi a versioni diverse delle specifiche ATTM e l'esistenza di percorsi di migrazione preferiti (prima la linea ferroviaria, prima il materiale rotabile o entrambi contemporaneamente), e che specifichi l'orizzonte temporale indicativo e le priorità della migrazione.

7.3.5.   Processo di gestione del cambiamento — requisiti

Come già indicato in precedenza, il cambiamento è un aspetto che interessa tutti i grandi sistemi basati su software. È quindi opportuno definire procedure di gestione del cambiamento che permettano di applicare i cambiamenti in condizioni controllate, nonché di analizzarne correttamente i vantaggi. A tal fine, il processo di gestione del cambiamento e i relativi strumenti devono garantire un rapporto favorevole tra costi ed efficacia nella registrazione e nell'applicazione dei cambiamenti. A prescindere dalle caratteristiche specifiche precise che saranno definite, tale processo dovrebbe essere sostanzialmente modellato su un approccio strutturato come nel diagramma seguente:

Alla base del processo di gestione descritto in precedenza dovrebbe esserci un piano di gestione della configurazione che includa l'insieme di norme e procedure per la gestione del cambiamento. I requisiti generali di tale piano sono descritti al paragrafo 7.3.6 successivo. È opportuno che la strategia di attuazione dei cambiamenti approvati sia formalizzata (sulla base del processo e della documentazione opportuni) in un piano di gestione del cambiamento che comprenda in particolare:

—	l'individuazione dei vincoli tecnici sottesi al cambiamento,

—	l'indicazione del soggetto su cui ricade la responsabilità delle procedure di attuazione del cambiamento,

—	la procedura di validazione dei cambiamenti da attuare,

—	la politica per la gestione del cambiamento, il rilascio, la migrazione e l'abbandono della soluzione precedente.

Un elemento importante del processo di gestione del cambiamento è la definizione delle responsabilità relative all'applicazione delle specifiche, sia sotto il profilo dell'assicurazione di qualità che per quanto riguarda la gestione della configurazione. La maggior parte di queste funzioni dovrebbe essere svolta dall'Agenzia ferroviaria europea [istituita ai sensi del regolamento (CE) n. 881/2004] o sotto la sua supervisione, quando tale organismo diverrà operativo. Il processo di gestione del cambiamento dovrebbe essere formalizzato nel corredo di documentazione di cui all'allegato A.

Infine, è essenziale che la composizione del Comitato per il controllo del cambiamento (CCC), a cui sarà affidata la funzione di autorità generale responsabile del sistema, sia rappresentativa di tutti i soggetti interessati: gestori dell'infrastruttura, imprese ferroviarie, imprese fornitrici, organismi notificati e autorità di regolamentazione. La partecipazione dei vari soggetti dovrebbe garantire una visione generale dei cambiamenti da introdurre e una valutazione globale delle loro implicazioni. Il CCC farà capo all'Agenzia ferroviaria europea.

7.3.6.   Piano di gestione della configurazione — requisiti

Il piano di gestione della configurazione dovrebbe descrivere l'insieme degli standard e delle procedure di gestione del cambiamento e in particolare indicare:

—	i soggetti che devono essere gestiti e un modello formale per l'individuazione di tali soggetti,

—	il soggetto su cui ricade la responsabilità delle procedure di gestione della configurazione e della presentazione dei soggetti controllati alla struttura competente per le decisioni in materia di gestione della configurazione,

—	le politiche di gestione della configurazione da utilizzare per il controllo del cambiamento e la gestione delle versioni,

—	la documentazione da conservare sul processo di gestione della configurazione,

—	gli strumenti da utilizzare per la gestione della configurazione e le procedure d'uso di tali strumenti,

—	una banca dati della configurazione in cui conservare i dati sulla configurazione.

Le caratteristiche specifiche dei processi di gestione della configurazione devono essere formalizzate per mezzo di specifiche che dovranno essere incluse nell'elenco dei documenti di cui all'allegato A.

7.4.   Casi specifici

7.4.1.   Introduzione

Le seguenti disposizioni particolari regolano i casi specifici indicati di seguito.

I casi specifici sono classificati in due categorie: disposizioni che trovano applicazione permanente (casi «P») o temporanea (casi «T»). Per quanto riguarda i casi temporanei, l'adeguamento degli Stati membri al sottosistema interessato è a volte raccomandato entro il 2010 (casi «T1»), come auspicato dalla decisione n. 1692/96/CE del Parlamento europeo e del Consiglio, del 23 luglio 1996, sugli orientamenti comunitari per lo sviluppo della rete transeuropea dei trasporti (11), a volte entro il 2020 (casi «T2»). Per «T aperto» si intende un periodo indeterminato che sarà precisato in una futura revisione della presente STI.

7.4.2.   Elenco dei casi specifici

7.4.2.1.   Stati membri UE confinanti con paesi terzi

Sul territorio degli Stati membri dell'UE confinanti con paesi terzi, le prescrizioni della presente STI non hanno carattere di obbligatorietà per i trasporti direttamente provenienti da o diretti verso tali paesi terzi (caso «T aperto»).

Tuttavia, se il percorso di trasporto si estende in un altro Stato membro dell'UE, le prescrizioni della presente STI devono avere piena applicazione, sempreché un accordo bilaterale o multilaterale tra gli Stati interessati o tra le IF e i GI che operano nel territorio di tali Stati membri non preveda diversamente.

7.4.2.2.   Grecia

Per i percorsi di trasporto effettuati su linee con scartamento pari a 1 000 mm, si applicano le normative nazionali.

---

(1)  GU L 75 del 15.3.2001, pag. 29. Direttiva modificata da ultimo dalla direttiva 2004/49/CE (GU L 164 del 30.4.2004, pag. 44; rettifica nella GU L 220 del 21.6.2004, pag. 16).

(2)  GU L 220 del 30.8.1993, pag. 23.

(3)  GU L 75 del 15.3.2001, pag. 26.

(4)  GU L 237 del 24.8.1991, pag. 25. Direttiva modificata da ultimo dalla direttiva 2004/51/CE del Parlamento europeo e del Consiglio (GU L 164 del 30.4.2004, pag. 164; rettifica nella GU L 220 del 21.6.2004, pag. 58).

(5)  Per «punto di partenza» si intende il punto in cui ha inizio la traccia; può trattarsi del punto di partenza della corsa del treno oppure di un punto di interscambio. Per «punto di trasferimento» si intende il punto in cui termina la traccia.

(6)  In altri termini, l'accesso a queste informazioni deve realizzarsi indipendentemente da quale sia il GI che le conserva, interamente o in parte.

(7)  Ad es. norme per l'assicurazione della qualità, metodologia di sviluppo del sistema, metodologia di prova, pianificazione della documentazione.

(8)  Applicazioni telematiche già operative prima dell'entrata in vigore della presente STI.

(9)  Una baseline ha la funzione di punto iniziale di riferimento ai fini della gestione controllata dell'evoluzione del sistema.

(10)  Versione del sistema distribuita ai clienti ferroviari. Versioni successive possono avere funzionalità e prestazioni diverse, o possono rimediare a difetti del sistema o a carenze riguardanti la sicurezza dei dati o la circolazione.

(11)  GU L 228 del 9.9.1996, pag. 1. Decisione modificata da ultimo dalla decisione n. 884/2004/CE (GU L 167 del 30.4.2004, pag. 1; rettifica nella GU L 201 del 7.6.2004, pag. 1).