EUR-Lex Access to European Union law
This document is an excerpt from the EUR-Lex website
Document 32006R0062
Commission Regulation (EC) No 62/2006 of 23 December 2005 concerning the technical specification for interoperability relating to the telematic applications for freight subsystem of the trans-European conventional rail system (Text with EEA relevance)
Regolamento (CE) n. 62/2006 della Commissione, del 23 dicembre 2005 , relativo alla specifica tecnica di interoperabilità per il sottosistema Applicazioni telematiche per il trasporto merci del sistema ferroviario transeuropeo convenzionale (Testo rilevante ai fini del SEE)
Regolamento (CE) n. 62/2006 della Commissione, del 23 dicembre 2005 , relativo alla specifica tecnica di interoperabilità per il sottosistema Applicazioni telematiche per il trasporto merci del sistema ferroviario transeuropeo convenzionale (Testo rilevante ai fini del SEE)
GU L 13 del 18/01/2006, p. 1–72
(ES, CS, DA, DE, ET, EL, EN, FR, IT, LV, LT, HU, NL, PL, PT, SK, SL, FI, SV) Questo documento è stato pubblicato in edizioni speciali
(BG, RO, HR)
No longer in force, Date of end of validity: 31/12/2014; abrogato da 32014R1305
18.1.2006 |
IT |
Gazzetta ufficiale dell'Unione europea |
L 13/1 |
REGOLAMENTO (CE) N. 62/2006 DELLA COMMISSIONE
del 23 dicembre 2005
relativo alla specifica tecnica di interoperabilità per il sottosistema Applicazioni telematiche per il trasporto merci del sistema ferroviario transeuropeo convenzionale
(Testo rilevante ai fini del SEE)
LA COMMISSIONE DELLE COMUNITÀ EUROPEE,
visto il trattato che istituisce la Comunità europea,
vista la direttiva 2001/16/CE del Parlamento europeo e del Consiglio, del 19 marzo 2001, relativa all'interoperabilità del sistema ferroviario transeuropeo convenzionale (1), in particolare l'articolo 6, paragrafo 1,
considerando quanto segue:
(1) |
A norma dell'articolo 2, lettera c), della direttiva 2001/16/CE, il sistema ferroviario transeuropeo convenzionale è diviso in sottosistemi di natura strutturale o funzionale. Ciascuno di questi sottosistemi deve essere oggetto di una specifica tecnica di interoperabilità (STI). |
(2) |
Il primo passo per istituire una STI consiste nell'elaborazione di un progetto di STI da parte dell'Associazione europea per l'interoperabilità ferroviaria (AEIF) che è stata designata quale organismo comune rappresentativo. |
(3) |
L'AEIF ha ricevuto l'incarico di redigere un progetto di STI per il sottosistema Applicazioni telematiche per il trasporto merci ai sensi dell'articolo 6, paragrafo 1, della direttiva 2001/16/CE. I parametri fondamentali per questo progetto di STI sono stati adottati con decisione 2004/446/CE della Commissione, del 29 aprile 2004, che determina i parametri fondamentali delle specifiche tecniche di interoperabilità riguardanti i sottosistemi Rumore, Carri merci e Applicazioni telematiche per il trasporto merci di cui alla direttiva 2001/16/CE (2). |
(4) |
Il progetto di STI redatto sulla base dei parametri fondamentali era accompagnato da una relazione introduttiva contente l'analisi costi-benefici di cui all'articolo 6, paragrafo 5, della direttiva. |
(5) |
Il progetto di STI è stato esaminato dal comitato istituito dall'articolo 21 della direttiva 96/48/CE del Consiglio, del 23 luglio 1996, relativa all'interoperabilità del sistema ferroviario transeuropeo ad alta velocità (3), e alla luce della relazione introduttiva. |
(6) |
Ai sensi dell'articolo 1 della direttiva 2001/16/CE, le condizioni per realizzare l'interoperabilità del sistema ferroviario transeuropeo convenzionale riguardano la progettazione, la costruzione, la ristrutturazione, il rinnovo e l'esercizio delle infrastrutture e del materiale rotabile che contribuiscono al funzionamento del sistema che entrerà in servizio dopo l'entrata in vigore della direttiva. Inoltre è ritenuta importante l'efficace interconnessione dei sistemi informativi e di comunicazione dei vari gestori e operatori dell'infrastruttura. |
(7) |
La maggior parte delle applicazioni telematiche esistenti per il trasporto merci è stata elaborata e realizzata in base alla normativa vigente nei singoli mercati nazionali. Questo fatto ostacola la continuità transfrontaliera dei servizi informativi, fattore fondamentale per garantire la qualità di servizi ferroviari internazionali, in particolare nel segmento in rapida crescita dei servizi internazionali di trasporto merci. |
(8) |
La STI telematica non deve imporre l'utilizzo di tecnologie o soluzioni tecniche specifiche, salvo nei casi in cui ciò sia assolutamente necessario per assicurare l'interoperabilità del sistema ferroviario transeuropeo convenzionale. |
(9) |
La STI telematica è basata sulle migliori conoscenze specifiche disponibili al momento della preparazione del relativo progetto. L'evoluzione della tecnologia, delle condizioni di esercizio, delle norme di sicurezza e delle norme in materia sociale può rendere necessarie modifiche o integrazioni della presente STI. A tal fine sarà definita una procedura per la gestione del controllo delle modifiche per consolidare e aggiornare le prescrizioni della STI. Questa procedura di aggiornamento sarà affidata all'Agenzia ferroviaria europea, istituita ai sensi del regolamento (CE) n. 881/2004 del Parlamento europeo e del Consiglio (4), non appena questa sarà operativa, vale a dire, al più tardi, entro aprile 2006. Ove necessario, sarà avviata, a norma dell'articolo 6, paragrafo 3, della direttiva 2001/16/CE, una procedura di revisione o di aggiornamento più approfondita e completa che comporti modifiche della procedura ordinaria definita nella presente STI. |
(10) |
L'applicazione della STI telematica deve tenere conto di criteri specifici relativi alla compatibilità tecnica e operativa tra le infrastrutture e il materiale rotabile da mettere in servizio e i servizi nei quali devono essere integrati. Queste esigenze di compatibilità comportano una complessa analisi tecnica ed economica che deve essere svolta caso per caso. Tale analisi deve prendere in considerazione le interfacce tra i vari sottosistemi di cui alla direttiva 2001/16/CE, le varie categorie di linee e di materiale rotabile di cui alla medesima direttiva e gli ambienti tecnici ed operativi della rete esistente. |
(11) |
È fondamentale, tuttavia, che una siffatta analisi sia svolta in un quadro coerente di linee guida e di norme di attuazione. A tal fine è necessario che gli organismi che rappresentano il settore ferroviario a livello europeo istituiscano una strategia europea per la concreta attuazione della STI telematica. Tale strategia deve indicare le fasi necessarie per passare dall'attuale frammentazione dei sistemi nazionali di gestione delle informazioni ad una situazione caratterizzata da uno scambio d'informazioni senza soluzioni di continuità lungo l'intera linea ferroviaria dell'Unione europea. |
(12) |
Per garantire un'attuazione efficiente della STI, è necessario elaborare un piano strategico europeo per la sua introduzione. A livello europeo devono essere coordinati piani di realizzazione progressiva, elaborati dai soggetti interessati, che tengano conto delle procedure e dei sistemi della tecnologia dell'informazione delle imprese ferroviarie e dei gestori dell'infrastruttura. Le imprese ferroviarie e i gestori dell'infrastruttura devono contribuire fornendo informazioni tecniche e funzionali sulle singole applicazioni telematiche esistenti per il trasporto merci. |
(13) |
Il sistema-obiettivo previsto nella STI deve fondarsi su una tecnologia informatica la cui vita operativa prevista è significativamente più breve rispetto a quella degli impianti ferroviari di segnalamento e telecomunicazione tradizionali. Per questo motivo esso richiede, per la sua introduzione, una strategia proattiva anziché reattiva, proprio al fine di evitare la potenziale obsolescenza del sistema prima della completa realizzazione delle interconnessioni. Inoltre, un'introduzione della STI in modo eccessivamente frammentato nel sistema ferroviario europeo comporterebbe spese generali e costi d'esercizio eccessivi a causa delle incertezze circa la continuità del servizio. L'elaborazione di un piano di attuazione coerente a livello europeo dovrebbe contribuire allo sviluppo armonioso di servizi d'informazione senza soluzione di continuità nell'intero sistema ferroviario europeo, nel rispetto della strategia comunitaria per la rete di trasporti transeuropei (TEN). Tale piano dovrà fondarsi sui correlati piani nazionali di attuazione e fornire tutte le informazioni necessarie per consentire ai vari soggetti interessati, in particolare alla Commissione, di prendere le decisioni di concessione di un sostegno finanziario ai progetti ferroviari. La Commissione deve avere la possibilità di predisporre i mezzi adeguati per garantire il coordinamento tra le varie parti nello sviluppo di un tale piano europeo. |
(14) |
Al fine di evitare confusioni, è necessario dichiarare che le disposizioni della decisione 2004/446/CE che riguardano i parametri di base del sistema ferroviario transeuropeo convenzionale non sono più applicabili. |
(15) |
La STI telematica per il trasporto merci ha natura funzionale. Di conseguenza, le disposizioni in essa contenute sono rivolte in pricipal modo ai soggetti attivi sul mercato. Ai fini dell'applicazione delle disposizioni della STI, un regolamento della Comunità destinato ad una ampia categoria di soggetti interessati risulta più appropriato di una decisione rivolta agli Stati membri. |
(16) |
Le misure di cui alla presente decisione sono conformi al parere del comitato istituito dalla direttiva 96/48/CE, |
HA ADOTTATO IL PRESENTE REGOLAMENTO:
Articolo 1
La specifica tecnica di interoperabilità (STI) relativa al sottosistema Applicazioni telematiche per il trasporto merci del sistema ferroviario convenzionale di cui all'articolo 6, paragrafo 1, della direttiva 2001/16/CE è definita nell'allegato del presente regolamento.
La STI è pienamente applicabile all'infrastruttura e al materiale rotabile del sistema ferroviario transeuropeo convenzionale definito nell'allegato I della direttiva 2001/16/CE.
Articolo 2
Le imprese ferroviarie e i gestori dell'infrastruttura contribuiscono fornendo entro sei mesi dall'entrata in vigore del presente regolamento informazioni tecniche e funzionali sulle singole applicazioni telematiche esistenti per il trasporto merci, definite nel capitolo 2 dell'allegato.
Articolo 3
Gli organismi rappresentativi del settore ferroviario operanti a livello europeo, definiti all'articolo 3, paragrafo 2, del regolamento (CE) n. 881/2004, elaborano un piano strategico europeo di attuazione per la STI allegata in base ai criteri specificati nel capitolo 7 dell'allegato al presente regolamento.
Essi comunicano tale piano strategico agli Stati membri e alla Commissione entro un anno dall'entrata in vigore del presente regolamento.
Articolo 4
Le disposizioni della decisione 2004/446/CE relative ai parametri di base del sistema ferroviario transeuropeo convenzionale cessano di avere efficacia alla data di entrata in vigore del presente regolamento.
Articolo 5
Il presente regolamento entra in vigore il giorno successivo alla pubblicazione nella Gazzetta ufficiale dell'Unione europea.
Il presente regolamento è obbligatorio in tutti i suoi elementi e direttamente applicabile in ciascuno degli Stati membri.
Fatto a Bruxelles, il 23 dicembre 2005.
Per la Commissione
Jacques BARROT
Vicepresidente
(1) GU L 110 del 20.4.2001, pag. 1. Direttiva modificata dalla direttiva 2004/50/CE (GU L 164 del 30.4.2004, pag. 114; rettifica nella GU L 220 del 21.6.2004, pag. 40).
(2) GU L 155 del 30.4.2004, pag. 1; rettifica nella GU L 193 dell'1.6.2004, pag. 1.
(3) GU L 235 del 17.9.1996, pag. 6. Direttiva modificata da ultimo dalla direttiva 2004/50/CE.
(4) GU L 164 del 30.4.2004, pag. 1; rettifica nella GU L 220 del 21.6.2004, pag. 3.
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).
«“Gestore dell'infrastruttura (GI)”: qualsiasi organismo o impresa incaricato in particolare della creazione e della manutenzione dell'infrastruttura ferroviaria, compresa eventualmente la gestione dei sistemi di controllo e di sicurezza dell'infrastruttura. I compiti di gestore dell'infrastruttura per una rete o parte di essa possono essere assegnati a diversi organismi o imprese.»
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.
«“Richiedente”: impresa ferroviaria titolare di una licenza e/o associazione internazionale di imprese ferroviarie e, negli Stati membri che prevedono tale possibilità, altre persone fisiche o giuridiche con un interesse di pubblico servizio o commerciale ad acquisire capacità di infrastruttura per la prestazione di un servizio ferroviario nei rispettivi territori, quali le autorità pubbliche di cui al regolamento (CEE) n. 1191/69, nonché i caricatori, gli spedizionieri e gli operatori di trasporti combinati.
“Impresa ferroviaria (IF)”: qualsiasi impresa pubblica o privata titolare di una licenza ai sensi delle vigenti disposizioni comunitarie, la cui attività principale consiste nella prestazione di servizi per il trasporto di merci e/o di persone per ferrovia e che garantisce obbligatoriamente la trazione; sono comprese anche le imprese che forniscono solo la trazione.»
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.
«La capacità di infrastruttura è assegnata dal gestore dell'infrastruttura e, una volta assegnata ad un richiedente, non può essere trasferita dal beneficiario ad un'altra impresa o servizio. Qualsiasi forma di transazione avente per oggetto la capacità di infrastruttura è vietata e ha come conseguenza l'esclusione da una nuova assegnazione di capacità. L'utilizzo della capacità da parte di un'impresa ferroviaria nello svolgimento delle attività di un richiedente che non è un'impresa ferroviaria non è considerato un trasferimento.»
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 sorveglianza e la manutenzione degli elementi fissi o mobili che partecipano alla circolazione dei treni devono essere organizzate, svolte e quantificate in modo da mantenerne la funzione nelle condizioni previste.»
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:
La conformità a questo requisito essenziale è assicurata in modo specifico dai seguenti paragrafi:
|
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:
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. 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:
|
— |
Riferimenti del messaggio, con le seguenti indicazioni:
|
— |
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:
|
— |
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:
|
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:
|
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:
|
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ò:
|
||||
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:
|
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
|
||||||||||||||||||||
Risposta |
: |
informazioni:
|
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
|
||||||||||||||||||||||
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):
|
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
|
||||||||||||
Risposta |
: |
informazioni:
|
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
|
||||||
Risposta |
: |
informazioni:
|
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
|
||||||||||||
Risposta |
: |
informazioni:
|
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 |
: |
|
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 |
: |
|
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
|
||||||||||||||||||
Risposta |
: |
informazioni
|
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 |
: |
L'IF e l'IFR devono poter accedere facilmente ai dati seguenti, conservati in banche dati:
|
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 |
: |
L'IF e l'IFR devono poter accedere facilmente ai dati seguenti, conservati in banche dati:
|
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 |
: |
|
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 |
: |
|
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 |
: |
Deve essere inoltre garantito un accesso agevole ai dati seguenti, conservati in banche dati:
|
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 |
: |
Deve essere inoltre garantito un accesso agevole ai dati seguenti, conservati in banche dati:
|
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 |
: |
|
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 |
: |
|
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 |
: |
Deve essere inoltre garantito un accesso agevole ai dati seguenti, conservati in banche dati:
|
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 |
: |
Deve essere inoltre garantito un accesso agevole ai dati seguenti, conservati in banche dati:
|
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 |
: |
|
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 |
: |
|
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:
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:
|
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:
|
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:
|
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:
|
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:
|
Possibilità di inviare richieste di traccia in gestione operativa. Vantaggi:
|
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:
|
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:
|
Invio della composizione del treno generata in modo prevalentemente automatico, elevata affidabilità dei dati, aggiornamento automatico nella registrazione dei dati della fase 3. Vantaggi:
|
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:
|
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:
|
Disponibilità della posizione e dell’orario stimato del treno, utilizzabili per il calcolo dell’ETI/ETA del carro/spedizione. Vantaggi:
|
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:
|
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:
|
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:
|
Gestione degli scostamenti e richieste di informazioni rilevanti. Vantaggi:
|
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:
|
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).
ALLEGATO A
ELENCO DEI DOCUMENTI ACCOMPAGNATORI
Elenco delle specifiche obbligatorie
Documento |
Riferimento |
Titolo del documento |
Versione |
1 |
AEIF_TAF_MesData_V11_041021.doc |
CR Telematic Applications for freight: Data Definitions and Messages |
1.1 |
2 |
AEIF_TAF_DbsData_V10_040322.doc |
CR Telematic Applications for freight: The Infrastructure Data and the Rolling Stock Data |
1.0 |
3 |
AEIF_TAF_ConData_V10_040622.doc |
CR Telematic Applications for freight: The Consignment Note Data and Description |
1.0 |
4 |
AEIF_TAF_Patdata_V10_040622.doc |
CR Telematic Applications for freight: The Train Path Data and Description |
1.0 |
5 |
AEIF_TAF_FigSeq_V10_040622.doc |
CR Telematic Applications for freight: Figures and Sequence Diagrams of the TAF TSI Messages |
1.0 |
6 |
AEIF_TAF_CofMgt_V10_041012.doc imminente |
TAF Configuration Management, Concept and Generic Requirements |
1.0 |
ALLEGATO B
GLOSSARIO
Termine |
Descrizione |
||||||||||||||||||||||||||||||||||||||||||||||||||
ACID |
Atomicità, Consistenza, Isolamento, Durabilità (persistenza). Sono le quattro proprietà principali che devono essere garantite in ogni transazione.
Il concetto ACID è descritto nella norma ISO/IEC 10026-1:1992 Section 4. Ciascuna di queste proprietà può essere misurata mediante benchmark. In genere, però, viene designato un transaction manager o transaction monitor cui è affidato il compito di assicurare l'applicazione del concetto ACID. In un sistema distribuito, per garantire l'applicazione del concetto ACID si può utilizzare il protocollo 2PC (two-phase commit, con commit a due fasi): la transazione viene completata solo se tutti i siti che partecipano alla transazione indicano di essere pronti al commit, altrimenti non viene eseguita (rollback). |
||||||||||||||||||||||||||||||||||||||||||||||||||
AEIF |
Associazione europea per l'interoperabilità ferroviaria. Ai sensi della direttiva 2001/16/CE, l'AEIF è «l'organismo comune rappresentativo» formato dall'UIC, dall'UNIFE e dall'UITP. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Affidabilità, disponibilità, manutenibilità, sicurezza (RAMS) |
Affidabilità — Capacità di cominciare e continuare ad operare in condizioni operative specificate per un dato periodo di tempo, espressa in termini matematici. Disponibilità — Tempo trascorso in servizio rispetto al tempo trascorso fuori servizio, espresso in termini matematici. Manutenibilità — Capacità di un sistema di essere rimesso in servizio dopo un guasto, espressa in termini matematici. Sicurezza — Probabilità che il sistema dia origine a un evento pericoloso, espressa in termini matematici. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Autotrasporto |
Trasporto su strada. |
||||||||||||||||||||||||||||||||||||||||||||||||||
CA |
Certification Authority — organismo di certificazione. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Capacità dell'unità utilizzata |
Codice che indica in che misura l'unità è carica o vuota (ad es. piena, vuota, non completa). |
||||||||||||||||||||||||||||||||||||||||||||||||||
Carico |
Quantitativo di merce singolarmente identificabile che deve essere trasportata da un mittente a un destinatario con uno o più mezzi di trasporto conformemente a quanto indicato in un singolo documento di trasporto. Sinonimo: spedizione. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Carico unitario |
Carico composto da vari imballaggi singoli collocati su un unico pallet o uniti tra loro ad esempio attraverso cinghie in modo da formare una singola unità allo scopo di rendere più efficiente la manipolazione meccanica. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Carro completo |
Carico unitario in cui l'unità è costituita da un carro. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Cifratura |
Codifica dei messaggi. Decifratura: riconversione dei dati dal formato cifrato al formato originale. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Codice CN |
Codice doganale dei prodotti composto da otto cifre. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Codice di identificazione della locomotiva |
Numero identificativo univoco di una macchina di trazione. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Codice HS |
Codice doganale dei prodotti composto da 6 cifre, identiche alle prime 6 cifre del codice CN. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Componente di interoperabilità |
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 comprende i beni materiali e quelli immateriali, quali il software. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Data/orario di messa a disposizione |
Data/orario di effettiva o prevista messa a disposizione della merce da parte del cliente. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Data/orario effettivi di partenza |
Data (e orario) di partenza del mezzo di trasporto. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Dati primari |
Dati basilari da utilizzare come dati di riferimento in ingresso per i messaggi o come base per la funzionalità e il calcolo dei dati derivati. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Destinatario |
Soggetto a cui deve pervenire la merce. Sinonimo: Ricevitore. |
||||||||||||||||||||||||||||||||||||||||||||||||||
DEVE/DEVONO |
Questo termine, così come il termine «RICHIESTO», indica che la definizione è un requisito assoluto della specifica. |
||||||||||||||||||||||||||||||||||||||||||||||||||
DOVREBBE/DOVREBBERO |
Questo termine o l'aggettivo «RACCOMANDATO» indicano che in particolari circostanze potrebbero esistere validi motivi per ignorare un particolare elemento, ma che prima di optare per un'altra soluzione devono essere comprese e valutate con attenzione tutte le implicazioni di una scelta in tal senso. |
||||||||||||||||||||||||||||||||||||||||||||||||||
ETA |
Dall'inglese Estimated Time of Arrival. Orario previsto di arrivo dei carri presso il cliente. |
||||||||||||||||||||||||||||||||||||||||||||||||||
ETH |
Dall'inglese Estimated Time of Handover. Orario previsto di trasferimento di un treno da un GI a un altro. |
||||||||||||||||||||||||||||||||||||||||||||||||||
ETI |
Dall'inglese Estimated Time of Interchange. Orario previsto di interscambio di carri da un'IF a un'altra. |
||||||||||||||||||||||||||||||||||||||||||||||||||
FTP |
Dall'inglese File Transfer Protocol. Protocollo che consente il trasferimento di file tra sistemi informatici; fa parte del protocollo di rete TCP/IP. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Gateway |
Stazione, lungo il percorso di viaggio di un treno che trasporta unità intermodali, in cui il carico viene trasferito su altri carri. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Gestore dell'infrastruttura (GI) |
Cfr. GI. |
||||||||||||||||||||||||||||||||||||||||||||||||||
GGP |
Dall'inglese Gateway to Gateway Protocol, protocollo «gateway to gateway». Cfr. anche IP. |
||||||||||||||||||||||||||||||||||||||||||||||||||
GI |
Gestore dell'infrastruttura: qualsiasi organismo o impresa incaricato in particolare della creazione e della manutenzione dell'infrastruttura ferroviaria, compresa eventualmente la gestione dei sistemi di controllo e di sicurezza dell'infrastruttura. I compiti del gestore dell'infrastruttura per un corridoio o parte di esso possono essere assegnati a diversi organismi o imprese (direttiva 2001/14/CE). |
||||||||||||||||||||||||||||||||||||||||||||||||||
HTTP |
Dall'inglese Hypertext Transfer Protocol, protocollo di trasferimento di ipertesti. Protocollo client/server usato per il collegamento a server sul web. |
||||||||||||||||||||||||||||||||||||||||||||||||||
ICMP |
Dall'inglese Internet Control Message Protocol, protocollo di controllo dei messaggi Internet. Il protocollo ICMP viene utilizzato quando un gateway (cfr. GGP) o un host destinazione (cfr. IP) deve comunicare con un host sorgente, ad esempio per segnalare un errore nell'elaborazione del datagramma. L'ICMP utilizza il supporto di base dell'IP come se fosse un protocollo di livello superiore, anche se in realtà è parte integrante dell'IP e deve essere implementato in ogni modulo IP. I messaggi ICMP vengono usati in varie situazioni: ad esempio quando un datagramma non giunge a destinazione, quando il gateway non ha capacità di buffering per inoltrare un datagramma, e quando il gateway può fornire istruzioni all'host affinché trasmetta il traffico lungo una via più breve. Il protocollo IP non ha tra i suoi obiettivi l'affidabilità assoluta. Lo scopo dei messaggi di controllo non è garantire l'affidabilità dell'IP bensì fornire indicazioni su problemi esistenti nell'ambiente di comunicazione. Infatti, non v'è alcuna garanzia che un datagramma giungerà effettivamente a destinazione o che verrà spedito indietro un messaggio di controllo. Alcuni datagrammi potrebbero comunque non giungere a destinazione senza che la loro perdita sia in alcun modo segnalata. Se è richiesta l'affidabilità della comunicazione, i protocolli di livello superiore che utilizzano l'IP devono applicare procedure proprie per garantire tale caratteristica. I messaggi ICMP in genere segnalano errori nell'elaborazione dei datagrammi. Per evitare effetti valanga (messaggi riguardanti messaggi, ecc.), non viene inviato alcun messaggio ICMP su messaggi ICMP. Inoltre, i messaggi ICMP sono inviati solamente per errori di gestione del frammento zero di datagrammi frammentati. (Nel frammento zero l'offset è uguale a zero.) |
||||||||||||||||||||||||||||||||||||||||||||||||||
IF |
Cfr. Impresa ferroviaria. |
||||||||||||||||||||||||||||||||||||||||||||||||||
IFR |
Cfr. Impresa ferroviaria responsabile. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Impresa ferroviaria (IF) |
Qualsiasi impresa pubblica o privata la cui attività principale consiste nella prestazione di servizi per il trasporto di merci e/o di persone per ferrovia e che garantisce obbligatoriamente la trazione; sono comprese anche le imprese che forniscono soltanto la trazione. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Impresa ferroviaria responsabile (IFR) |
IF che organizza e gestisce la linea di trasporto in base al principio dell'attenzione per il cliente. Costituisce il punto unico di riferimento per il cliente. Se alla catena di trasporto partecipano più imprese ferroviarie, l'IFR è responsabile del coordinamento delle varie IF. Specialmente nel caso del trasporto intermodale, il cliente può essere un integratore di servizi intermodali. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Integratore di servizi intermodali |
Organismo o impresa che ha stipulato un contratto con un cliente per il trasporto di unità intermodali. Si occupa di redigere i titoli di trasporto, di gestire la capacità sui treni blocco, ecc. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Internet |
|
||||||||||||||||||||||||||||||||||||||||||||||||||
Interscambio |
Trasferimento del controllo da un'impresa ferroviaria a un'altra per ragioni pratiche di natura operativa o legate alla sicurezza, ad esempio:
|
||||||||||||||||||||||||||||||||||||||||||||||||||
IP |
Dall'inglese Internet Protocol, protocollo Internet. Il protocollo IP è utilizzato in un sistema di reti interconnesse per servizi di datagramma host-to-host. I dispositivi per il collegamento di reti sono denominati gateway. I gateway comunicano tra di loro con finalità di controllo attraverso un protocollo GGP (Gateway to Gateway Protocol). |
||||||||||||||||||||||||||||||||||||||||||||||||||
Itinerario |
Percorso geografico da coprire per giungere da un punto di partenza a un punto di destinazione. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Lettera di vettura |
Documento che indica l'esistenza di un contratto relativo al trasporto di un carico di merce da parte di un vettore da un luogo specificato di accettazione a un luogo specificato di consegna. Vi sono contenute informazioni dettagliate sul carico da trasportare. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Localizzazione |
In inglese tracking. Attività che consiste nel monitoraggio e nella registrazione continui della posizione e dello stato correnti di un determinato carico, veicolo, unità, imballaggio o trasporto merci. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Locatario |
Persona fisica o giuridica designata come tale dal titolare/proprietario di un carro. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Luogo di consegna |
Luogo in cui si effettua la consegna (stazione ferroviaria di partenza da indicare). Luogo in cui avviene il trasferimento della responsabilità per il carro. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Luogo di destinazione |
Luogo in cui è previsto o avviene l'arrivo di un mezzo di trasporto. Sinonimo: luogo di arrivo. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Luogo di partenza |
Luogo da cui è prevista o si effettua la partenza di un mezzo di trasporto. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Messa in servizio |
Procedura subordinata all'omologazione tecnica di un carro e a un contratto d'uso con un'IF che permette l'esercizio commerciale del carro. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Metadati |
In sintesi, dati che riguardano dati. Descrivono dati, servizi software e altri componenti compresi nei sistemi informativi dell'impresa. I metadati comprendono ad esempio le definizioni standard dei dati, le informazioni sull'ubicazione e sull'instradamento, e la gestione della sincronizzazione per la distribuzione di dati condivisi. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Mittente |
Soggetto che, in base a un contratto con un Integratore di servizi, invia o spedisce merci mediante un vettore, o le fa trasportare da un vettore. Sinonimi: Caricatore, speditore. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Modalità di accesso libero |
Modalità di esercizio di un treno che vede la partecipazione di una sola IF, la quale gestisce il treno su varie infrastrutture. L'IF stipula un contratto per le tracce orarie necessarie con tutti i GI interessati. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Modalità di cooperazione |
Modalità di esercizio di un treno in cui varie IF cooperano sotto la guida di una IF (IFR). Ciascuna delle IF partecipanti stipula autonomamente un contratto per la traccia oraria necessaria per il trasporto. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Modello di riferimento OSI |
Descrizione standard delle modalità con cui dovrebbe effettuarsi la trasmissione di messaggi tra due punti qualsiasi di una rete. Il modello OSI definisce 7 livelli di funzioni che si realizzano ai due capi della comunicazione. Tali livelli rappresentano l'unico insieme di standard di comunicazione riconosciuto a livello internazionale. |
||||||||||||||||||||||||||||||||||||||||||||||||||
NFS |
Dall'inglese Network File System, protocollo per file system distribuiti. Il protocollo NFS permette l'accesso remoto in modalità trasparente a file system condivisi su una rete. È progettato per essere indipendente da macchina, sistema operativo, architettura di rete, meccanismo di sicurezza e protocollo di trasporto. Questa indipendenza è ottenuta attraverso l'uso di primitive di invocazione remota di procedura (RPC, Remote Procedure Call) costruite sopra una rappresentazione esterna di dati (XDR, eXternal Data Representation). |
||||||||||||||||||||||||||||||||||||||||||||||||||
NON DEVE/NON DEVONO |
Questo termine indica che la definizione è un divieto assoluto della specifica. |
||||||||||||||||||||||||||||||||||||||||||||||||||
NON DOVREBBE/NON DOVREBBERO |
Questa frase o la frase «NON RACCOMANDATO» indicano che in particolari circostanze potrebbero esistere validi motivi per i quali un particolare comportamento è accettabile o anche utile, ma che prima di mettere in pratica tale comportamento dovrebbero essere comprese e valutate con attenzione tutte le implicazioni del caso. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Numero di traccia |
Numero di una determinata traccia oraria. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Numero ONU |
Numero identificativo delle merci pericolose attribuito dall'Organizzazione delle Nazioni Unite. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Numero RID |
Numero identificativo delle merci pericolose attribuito dall'OTIF. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Operatore intermodale |
Operatore di un terminale intermodale, ad es. un gateway. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Orario di messa a disposizione dei carri |
Data e orario in cui i carri sono pronti per lasciare il punto indicato, situato nei raccordi del cliente. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Orario previsto |
Migliore stima dell'orario di arrivo, partenza o transito di un treno. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Orario previsto di arrivo del treno |
In inglese Train Estimated Time of Arrival, TETA. Orario previsto di arrivo di un treno in un punto specifico, che può essere ad esempio un punto di trasferimento, un punto di interscambio o la destinazione del treno. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Orario programmato |
Occupazione dell'infrastruttura ferroviaria per la circolazione di un treno in piena linea o in stazioni, definita cronologicamente. Le variazioni degli orari sono indicate dal GI almeno 2 giorni prima dell'inizio del giorno di partenza del treno dal punto di origine. L'orario si applica a un giorno specifico. In alcuni paesi, prende il nome di orario operativo. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Orario programmato di partenza |
Data e orario di partenza per i quali è richiesta la traccia. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Organismi notificati |
Organismi incaricati di valutare la conformità o l'idoneità all'impiego dei componenti di interoperabilità o di istruire la procedura di verifica CE dei sottosistemi (direttiva 1991/440/CE). |
||||||||||||||||||||||||||||||||||||||||||||||||||
OSI |
Dall'inglese Open Systems Interconnection, interconnessione di sistemi aperti. Descrive un protocollo di comunicazione tra sistemi aperti basato sul modello di riferimento OSI. I sistemi aperti sono in grado di comunicare indipendentemente da soluzioni proprietarie. |
||||||||||||||||||||||||||||||||||||||||||||||||||
OSS |
Dall'inglese One Stop Shop, sportello unico (cfr.) |
||||||||||||||||||||||||||||||||||||||||||||||||||
Peer-to-Peer |
Letteralmente «da pari a pari». Il termine si riferisce a una classe di sistemi e applicazioni che utilizzano risorse distribuite per eseguire una funzione critica in modo decentrato. Le risorse comprendono potenza di elaborazione, dati (memorizzazione e contenuto), larghezza di banda di rete e presenza (computer, risorse umane e risorse di altro tipo). La funzione critica può essere costituita ad esempio da servizi di elaborazione distribuita, condivisione di dati/contenuti, comunicazione e collaborazione o servizi di piattaforma. Il decentramento può applicarsi ad algoritmi, dati o metadati, singolarmente o collettivamente. Non esclude che venga mantenuto un certo livello di centralizzazione in alcune parti dei sistemi e delle applicazioni, se i relativi requisiti sono soddisfatti. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Percorso |
Il termine «percorso» si utilizza in riferimento all'istradamento di un carro carico o vuoto dalla stazione di partenza a quella di destinazione. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Periodo prepartenza |
Delta tempo mancante all'orario programmato di partenza. Il periodo prepartenza ha inizio all'orario programmato di partenza meno delta tempo e termina all'orario programmato di partenza. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Peso lordo del carico |
Peso (massa) totale prenotato/effettivo delle merci e dell'imballaggio, ad esclusione dell'unità del vettore. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Piano di inoltro |
Per un carro o un'unità intermodale, indica il percorso di riferimento programmato del carro/unità intermodale. |
||||||||||||||||||||||||||||||||||||||||||||||||||
PKI |
Dall'inglese Public Key Infrastructure, infrastruttura a chiave pubblica. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Prenotazione |
Procedura che consiste nel riservare spazio su un mezzo di trasporto per la movimentazione di merci. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Prodotto COTS |
Dall'inglese Commercially Off the Shelf, prodotto esistente in commercio. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Punto di interscambio |
Luogo in cui la responsabilità dei carri di un treno passa da un'IF a un'altra IF. Per i treni in marcia, la responsabilità del treno viene trasferita da un'IF all'IF proprietaria della traccia oraria per la sezione di percorso successiva. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Punto di manipolazione |
Stazione in cui l'IF può variare la composizione del treno rimanendo però responsabile dei carri (non vi è trasferimento di responsabilità). |
||||||||||||||||||||||||||||||||||||||||||||||||||
Punto di segnalazione |
Luogo, lungo il percorso di un treno, in cui il GI responsabile deve trasmettere un messaggio Previsione di marcia del treno completo di TETA all'IF con cui ha stipulato un contratto per la traccia oraria. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Punto di trasferimento |
Punto in cui si attua il passaggio di responsabilità da un GI a un altro. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Punto intermedio |
Luogo che identifica il punto iniziale o finale di una sezione di percorso. Può trattarsi ad es. di un punto di interscambio, trasferimento o manipolazione. |
||||||||||||||||||||||||||||||||||||||||||||||||||
PUÒ/POSSONO |
Questo termine, così come gli aggettivi «OPZIONALE» e «FACOLTATIVO», indica che un elemento è puramente facoltativo. Un produttore può decidere di includere un elemento perché un particolare mercato lo richiede o perché ritiene che il prodotto ne risulti migliorato, mentre un altro produttore può omettere lo stesso elemento. Un'implementazione che non include una particolare opzione DEVE essere in grado di interoperare con un'altra implementazione che la include, sia pure con ridotte funzionalità. Allo stesso modo, un'implementazione che include una particolare opzione DEVE essere in grado di interoperare con un'altra implementazione che non la include (eccetto per la particolare funzionalità che l'opzione consente). |
||||||||||||||||||||||||||||||||||||||||||||||||||
RAMS |
Dall'inglese Reliability, Availability, Maintainability, Safety. Cfr. Affidabilità, disponibilità, manutenibilità, sicurezza. |
||||||||||||||||||||||||||||||||||||||||||||||||||
RARP |
Dall'inglese Reverse Address Resolution Protocol, protocollo inverso per la risoluzione degli indirizzi. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Repository |
Un repository (deposito) è simile a un database e a un data dictionary, ma in genere comprende un ambiente globale per il sistema di gestione delle informazioni. Oltre alla descrizione delle strutture dei dati (vale a dire entità ed elementi), vi devono essere inclusi anche metadati di interesse per l'impresa, schermate di dati, report, programmi e sistemi. In genere comprende una serie interna di strumenti software, un DBMS, un metamodello, metadati popolati e programmi software dedicati al caricamento e al recupero per l'accesso ai dati del repository. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Requisiti essenziali |
Condizioni descritte nell'allegato III della direttiva 2001/16/CE che devono essere soddisfatte dal sistema ferroviario transeuropeo convenzionale, dai sottosistemi e dai componenti di interoperabilità, comprese le interfacce. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Rete ferroviaria transeuropea |
Rete ferroviaria descritta nell'allegato I della direttiva 2001/16/CE. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Richiedente |
Impresa ferroviaria titolare di una licenza e/o associazione internazionale di imprese ferroviarie e, negli Stati membri che prevedono tale possibilità, altre persone fisiche o giuridiche con un interesse di pubblico servizio o commerciale ad acquisire capacità di infrastruttura per la prestazione di un servizio ferroviario nei rispettivi territori, quali le autorità pubbliche di cui al regolamento (CEE) n. 1191/69 del Consiglio (1), nonché i caricatori, gli spedizionieri e gli operatori di trasporti combinati. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Richiesta di carri |
Sottoinsieme della lettera di vettura in cui sono contenute le informazioni pertinenti che consentono a un'IF di effettuare il trasporto per il tratto di sua competenza fino al trasferimento all'IF successiva. Istruzioni per il trasporto di una spedizione su un carro. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Richiesta di traccia oraria in gestione operativa |
Richiesta singola di traccia oraria a norma dell'articolo 23 della direttiva 2001/14/CE dovuta a richieste aggiuntive di trasporto o a esigenze operative. |
||||||||||||||||||||||||||||||||||||||||||||||||||
RID |
Norme riguardanti il trasporto internazionale di merci pericolose a mezzo ferrovia. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Rintracciamento |
In inglese tracing. Attività che si effettua in risposta alla richiesta di individuare e ricostruire la storia del trasporto di un determinato carico, veicolo, unità, imballaggio o trasporto merci. |
||||||||||||||||||||||||||||||||||||||||||||||||||
RIV |
Normativa che disciplina l'uso reciproco dei carri nel traffico internazionale. Normativa che disciplina l'uso reciproco di attrezzi di carico, container e pallet nel traffico internazionale. |
||||||||||||||||||||||||||||||||||||||||||||||||||
RPC |
Dall'inglese Remote Procedure Call, chiamata a procedura remota. Le caratteristiche del protocollo RPC sono definite nella specifica RFC1831, versione 2. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Sezione di itinerario |
Parte di un itinerario. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Sezione di percorso |
Parte del percorso che si effettua nel settore di infrastruttura di un gestore dell'infrastruttura; oppure parte del percorso compresa fra il punto di trasferimento di ingresso e il punto di trasferimento di uscita sull'infrastruttura di un gestore dell'infrastruttura. |
||||||||||||||||||||||||||||||||||||||||||||||||||
SMTP |
Dall'inglese Simple Mail Transfer Protocol, semplice protocollo per il trasferimento di posta. |
||||||||||||||||||||||||||||||||||||||||||||||||||
SNMP |
Dall'inglese Simple Network Management Protocol, semplice protocollo per la gestione di reti. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Soggetti interessati |
Qualsiasi persona od organizzazione avente un interesse plausibile nella fornitura di servizi ferroviari, ad esempio:
Nel caso dei trasporti intermodali, anche:
|
||||||||||||||||||||||||||||||||||||||||||||||||||
Soggetto erogatore di servizi |
Vettore responsabile di uno stadio specifico del trasporto. Soggetto che riceve e gestisce la prenotazione. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Soggetto obbligato |
Persona fisica o giuridica responsabile del rischio che immette nella rete, vale a dire l'IF. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Specifica tecnica di interoperabilità (STI) |
Specifica elaborata per ciascun sottosistema o parte di sottosistema al fine di garantire il soddisfacimento dei requisiti essenziali e l'interoperabilità del sistema ferroviario transeuropeo convenzionale. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Spedizione |
Insieme di merci che viaggia da un mittente a un destinatario in una o più unità complete del GI o su uno o più carri completi. Ad es.: |
||||||||||||||||||||||||||||||||||||||||||||||||||
Sportello unico |
In inglese One Stop Shop (OSS). Forma di partenariato internazionale tra gestori dell'infrastruttura ferroviaria che mette a disposizione dei clienti un singolo interlocutore il quale si occupa di:
|
||||||||||||||||||||||||||||||||||||||||||||||||||
SQL |
Dall'inglese Structured Query Language, linguaggio strutturato di interrogazione. Linguaggio ideato da IBM e successivamente standardizzato da norme ANSI e ISO, utilizzato per creare, gestire e recuperare dati in database relazionali. |
||||||||||||||||||||||||||||||||||||||||||||||||||
STI |
Cfr. Specifica tecnica di interoperabilità. |
||||||||||||||||||||||||||||||||||||||||||||||||||
TCP |
Dall'inglese Transmission Control Protocol, protocollo per il controllo della trasmissione. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Terminale intermodale |
Luogo che mette a disposizione lo spazio, le attrezzature e l'ambiente operativo per il trasferimento delle unità per il carico (container, casse mobili, semirimorchi o rimorchi). |
||||||||||||||||||||||||||||||||||||||||||||||||||
TETA |
Cfr. Orario previsto di arrivo del treno. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Titolare |
Persona che, in qualità di titolare della proprietà o del diritto di disporre di un veicolo, sfrutta economicamente detto veicolo come mezzo di trasporto in maniera stabile ed è iscritto in tale veste al Registro del materiale rotabile. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Titolo di trasporto |
Documento predisposto dal vettore o per conto del vettore che indica l'esistenza di un contratto per il trasporto di merci. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Traccia oraria |
Percorso di un treno definito in termini temporali e geografici. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Traccia oraria o traccia |
Capacità di infrastruttura necessaria a far viaggiare un treno tra due località in un determinato periodo temporale (percorso definito nel tempo e nello spazio). |
||||||||||||||||||||||||||||||||||||||||||||||||||
Traccia oraria/Slot |
Definizione del percorso di un treno con riferimento al tempo e alle località (punti indicatori) di origine e destinazione, e informazioni sulle località in cui transiterà o si fermerà lungo il percorso. Tali informazioni possono comprendere eventuali attività che saranno effettuate lungo il percorso, ad esempio il cambio del personale viaggiante, della locomotiva o altre variazioni della composizione del treno. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Trasbordo |
Trasferimento di merce o unità di carico da un veicolo a un altro o a un deposito e viceversa. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Trasporto ferroviario combinato |
Trasporto intermodale in cui la percorrenza in territorio europeo si effettua principalmente per ferrovia, mentre gli eventuali percorsi iniziale e/o terminale, quanto più brevi possibile, si realizzano su strada. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Trasporto intermodale |
Trasferimento di merce effettuato utilizzando una medesima unità per il carico o un medesimo veicolo ma più modi di trasporto in successione, senza rottura di carico. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Treno blocco |
Tipo specifico di treno diretto formato dal numero di carri strettamente necessario, che viaggia tra due punti di trasbordo senza smistamento intermedio. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Treno completo |
Treno merci composto da carri dello stesso tipo che viaggia con un'unica lettera di vettura e un unico tipo di merci da un mittente a un destinatario senza smistamento intermedio. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Treno diretto |
Treno (con i relativi vagoni) che viaggia tra due punti di trasbordo (origine iniziale-destinazione finale) senza smistamento intermedio. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Tunnelling |
Processo che consiste nell'incapsulare pacchetti IP privati in un pacchetto IP pubblico. |
||||||||||||||||||||||||||||||||||||||||||||||||||
UDP |
Dall'inglese User Datagram Protocol, protocollo datagramma utente. Il protocollo STUN [Simple Traversal of UDP (User Datagramma Protocol) through NATs (Network Address Translators)] è un protocollo leggero che permette alle applicazioni di determinare la presenza e i tipi di NAT e firewall presenti tra le medesime applicazioni e la rete Internet pubblica, nonché gli indirizzi IP (Internet Protocol) pubblici assegnati loro dal NAT. Il protocollo STUN funziona con molti NAT esistenti e non richiede da parte loro comportamenti particolari. Per questo, consente a una vasta gamma di applicazioni di funzionare nell'infrastruttura NAT esistente. |
||||||||||||||||||||||||||||||||||||||||||||||||||
UIC |
Unione internazionale delle ferrovie. |
||||||||||||||||||||||||||||||||||||||||||||||||||
UITP |
Organo di cooperazione internazionale dei gestori del traffico. |
||||||||||||||||||||||||||||||||||||||||||||||||||
UNIFE |
Organizzazione che cura gli interessi dei fornitori del settore ferroviario. Rappresenta direttamente circa 100 fornitori e subappaltatori, e indirettamente altri 1 000 attraverso le organizzazioni nazionali. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Unione di tracce |
L'unione di singole tracce orarie effettuata allo scopo di accrescerne l'estensione geografica e temporale. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Unità intermodale |
Unità di carico che può essere trasportata con modi di trasporto diversi, ad es. container, cassa mobile, semirimorchio, rimorchio. |
||||||||||||||||||||||||||||||||||||||||||||||||||
VPN |
Dall'inglese Virtual Private Network, rete privata virtuale. Il termine Virtual Private Network è stato impiegato per descrivere quasi tutti i tipi di sistemi per la connettività remota, ad esempio la rete telefonica pubblica ed i PVC (circuiti virtuali permanenti) in Frame Relay. Con l'introduzione di Internet, il termine VPN è divenuto sinonimo di reti dati remote basate su IP. In breve, una VPN è costituita da due o più reti private che comunicano in modo sicuro su una rete pubblica. Le VPN possono collegare una singola macchina a una rete privata (client-to-server) o una LAN remota a una rete privata (server-to-server). Le reti private possono connettersi tramite tunnelling. Di solito, le VPN utilizzano Internet come rete per la trasmissione ma ricorrono alla cifratura dei dati trasmessi tra un cliente VPN e un gateway VPN per evitare che vengano letti nel caso in cui vengano intercettati durante la trasmissione. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Web |
World Wide Web. Servizio Internet che permette di accedere a documenti attraverso collegamenti ipertestuali tra server e server: in questo modo gli utenti possono passare da un documento a un documento collegato indipendentemente dal server in cui esso risiede. |
||||||||||||||||||||||||||||||||||||||||||||||||||
XDR |
Dall'inglese External Data Representation, rappresentazione di dati esterni. Le caratteristiche del protocollo XDR sono definite nella specifica RFC1832 (External Data Representation Standard). L'XDR è uno standard relativo alla descrizione e alla codifica dei dati. È utile per trasferire dati tra sistemi di elaborazione con architetture diverse. Si inserisce nel livello presentazione del modello ISO ed ha finalità a grandi linee analoghe a quelle dell'X.409 (Abstract Syntax Notation) definito dall'ISO. La differenza principale è che l'XDR utilizza riferimenti impliciti, mentre l'X.409 utilizza riferimenti espliciti. L'XDR utilizza un linguaggio per descrivere i formati di dati. Tale linguaggio serve solo per descrivere i dati; non è un linguaggio di programmazione. Permette di descrivere formati complessi in maniera concisa. L'alternativa, che consiste nell'uso di rappresentazioni grafiche (linguaggio informale), diventa rapidamente incomprensibile con il crescere della complessità. Il linguaggio XDR è simile al linguaggio C. Protocolli quale l'ONC RPC (Remote Procedure Call) e l'NFS (Network File System) utilizzano l'XDR per descrivere il formato dei propri dati. Lo standard XDR si basa sull'assunto della portabilità dei byte (o ottetti — 8 bit di dati). Un dato dispositivo hardware dovrebbe codificare i byte sui vari supporti in modo tale che altri dispositivi hardware li possano decodificare senza perdite di significato. |
||||||||||||||||||||||||||||||||||||||||||||||||||
XML-RPC |
Dall'inglese eXtensible Mark-up Language-Remote Procedure Calling, linguaggio di markup estensibile-chiamata a procedura remota. Si tratta di un protocollo per Internet che definisce un formato XML per i messaggi trasferiti tra client e server via HTTP. Un messaggio XML-RPC codifica una procedura che deve essere invocata dal server, unitamente ai parametri da utilizzare nell'invocazione, oppure il risultato di un'invocazione. I parametri della procedura e i risultati possono essere dati scalari, numeri, stringhe, date, ecc., e anche strutture complesse di record e liste. Questo documento specifica come utilizzare il protocollo BEEP (Blocks Extensible Exchange Protocol) per trasferire messaggi codificati in formato XML-RPC tra client e server. |
||||||||||||||||||||||||||||||||||||||||||||||||||
XQL |
Dall'inglese Extended Structured Query Language, linguaggio strutturato di interrogazione esteso. |
(1) GU L 156 del 28.6.1969, pag. 1. Regolamento modificato da ultimo dal regolamento (CEE) n. 1893/91 (GU L 169 del 29.6.1991, pag. 1).