18.1.2006 |
FR |
Journal officiel de l'Union européenne |
L 13/1 |
RÈGLEMENT (CE) no 62/2006 DE LA COMMISSION
du 23 décembre 2005
relatif à la spécification technique d'interopérabilité concernant le sous-système «Applications télématiques au service du fret» du système ferroviaire transeuropéen conventionnel
(Texte présentant de l'intérêt pour l'EEE)
LA COMMISSION DES COMMUNAUTÉS EUROPÉENNES,
vu le traité instituant la Communauté européenne,
vu la directive 2001/16/CE du Parlement européen et du Conseil du 19 mars 2001 relative à l'interopérabilité du système ferroviaire transeuropéen conventionnel (1), et notamment son article 6, paragraphe 1,
considérant ce qui suit:
(1) |
Conformément à l'article 2, point c), de la directive 2001/16/CE, le système ferroviaire transeuropéen conventionnel est subdivisé en sous-systèmes de nature structurelle ou fonctionnelle. Chacun des sous-systèmes doit faire l'objet d'une spécification technique d'interopérabilité (ci-après dénommée «STI»). |
(2) |
Lors de la définition d'une STI, la première étape est l'élaboration d'un projet de STI par l'Association européenne pour l'interopérabilité ferroviaire (AEIF), qui a été désignée comme organisme commun représentatif. |
(3) |
L'AEIF a reçu mandat de rédiger un projet de STI relative au sous-système «Applications télématiques au service du fret» conformément à l'article 6, paragraphe 1, de la directive 2001/16/CE. Les paramètres fondamentaux pour ce projet de STI ont été adoptés par la décision 2004/446/CE de la Commission du 29 avril 2004 précisant les paramètres fondamentaux des spécifications techniques d'interopérabilité concernant les sous-systèmes bruit, wagons pour le fret et applications télématiques au service du fret visées dans la directive 2001/16/CE (2). |
(4) |
Le projet de STI élaboré sur la base des paramètres fondamentaux a été assorti d'un rapport de présentation comportant une analyse des coûts et avantages, comme prévu à l'article 6, paragraphe 5, de ladite directive. |
(5) |
Le projet de STI a été examiné par le comité institué par l'article 21 de la directive 96/48/CE du Conseil du 23 juillet 1996 relative à l'interopérabilité du système ferroviaire transeuropéen à grande vitesse (3), à la lumière du rapport de présentation. |
(6) |
Conformément à l'article 1er de la directive 2001/16/CE, les conditions pour réaliser l'interopérabilité du système ferroviaire transeuropéen conventionnel concernent la conception, la construction, l'aménagement, le renouvellement ainsi que l'exploitation des infrastructures et du matériel roulant concourant au fonctionnement de ce système, qui seront mis en service après la date d'entrée en vigueur de la directive. Une interconnexion efficace des systèmes d'information et de communication des différents gestionnaires d'infrastructures et exploitants est en outre considérée comme importante. |
(7) |
La plupart des applications télématiques pour le transport de marchandises existantes ont été conçues et mises en œuvre en tenant compte des exigences des marchés nationaux. Cela gêne la continuité des services d'information entre les différents pays, or celle-ci est un élément essentiel de la qualité des services ferroviaires internationaux, en particulier sur le marché en plein essor des services internationaux de transport de marchandises. |
(8) |
Une STI sur les applications télématiques ne doit pas imposer l'utilisation de technologies ou de solutions techniques spécifiques, excepté lorsque cela est strictement nécessaire pour l'interopérabilité du réseau ferroviaire transeuropéen conventionnel. |
(9) |
La STI sur les applications télématiques s'appuie sur les meilleures connaissances spécialisées disponibles au moment de la préparation du projet correspondant. Il peut être nécessaire de modifier ou de compléter cette STI pour tenir compte de l'évolution des techniques ou des exigences sociales, de fonctionnement ou de sécurité. À cette fin, une procédure de gestion des modifications sera élaborée pour harmoniser et mettre à jour les dispositions de la STI. Cette procédure de mise à jour sera placée sous la direction de l'Agence ferroviaire européenne instituée par le règlement (CE) no 881/2004 du Parlement européen et du Conseil (4), lorsque l'Agence sera en activité, à savoir en avril 2006 au plus tard. Si nécessaire, une procédure d'examen ou de mise à jour plus approfondie et plus complète entraînant des modifications de la procédure régulière définie dans cette STI sera engagée conformément à l'article 6, paragraphe 3, de la directive 2001/16/CE. |
(10) |
La mise en œuvre de la STI relative aux applications télématiques doit tenir compte de critères spécifiques de compatibilité technique et opérationnelle entre les infrastructures et le matériel roulant à mettre en service et les systèmes dans lesquels ils s'intègrent. Ces exigences de compatibilité impliquent une analyse technique et économique complexe qui doit être réalisée au cas par cas. Cette analyse doit prendre en considération les interfaces entre les différents sous-systèmes visés par la directive 2001/16/CE, les différentes catégories de lignes et de matériel roulant visés par cette directive et les environnements technique et opérationnel du réseau existant. |
(11) |
Il est cependant essentiel que cette analyse soit effectuée dans le cadre de règles et de directives d'application cohérentes. Pour ce faire, les organismes représentatifs du secteur ferroviaire au niveau européen devront définir une stratégie européenne pour la mise en œuvre de la STI relative aux applications télématiques. Cette stratégie devra indiquer les étapes à franchir pour évoluer de la situation actuelle où les systèmes de gestion de l'information sont segmentés vers une situation où l'information circule de manière fluide sur l'ensemble du réseau ferroviaire de l'Union européenne. |
(12) |
Un plan stratégique européen de déploiement doit être défini pour garantir une mise en œuvre efficace de la STI. Des plans de mise en œuvre progressive, que les parties prenantes doivent élaborer, doivent être coordonnés au niveau européen et tenir compte des procédés et des systèmes de technologie de l'information des entreprises ferroviaires et des gestionnaires d'infrastructures. À cette fin, les entreprises ferroviaires et les gestionnaires d'infrastructures doivent apporter leur contribution en fournissant des informations fonctionnelles et techniques concernant les différentes applications télématiques pour le transport de marchandises existantes. |
(13) |
Le système cible requis dans la STI doit reposer sur une technologie informatique dont la durée de vie utile prévue est bien moindre que celle des équipements de télécommunication et de signalisation du système ferroviaire traditionnel actuel. Partant, il convient d'adopter une stratégie de déploiement volontariste plutôt que réactive pour éviter que le système ne devienne obsolète avant que toutes les interconnexions aient été complètement établies. En outre, un déploiement fragmenté sur l'ensemble du système ferroviaire européen engendrerait des charges d'exploitation et des coûts supplémentaires importants en raison de l'incertitude concernant la continuité du service. L'établissement d'un cadre cohérent au niveau européen contribuerait à la mise en place harmonieuse de services d'information continus sur l'ensemble du réseau ferroviaire transeuropéen, conformément à la stratégie communautaire pour le réseau de transport transeuropéen. Un tel plan doit être fondé sur les plans nationaux de mise en œuvre correspondants et fournir une base de connaissances appropriées pour soutenir la prise de décision par les différentes parties prenantes — notamment par la Commission pour l'octroi d'un soutien financier aux projets ferroviaires. La Commission doit être autorisée à faciliter la mise en place des moyens appropriés pour garantir la coordination des parties concernées par la définition d'un tel cadre européen. |
(14) |
Pour éviter toute confusion, il est nécessaire de préciser que les dispositions de la décision 2004/446/CE relatives aux paramètres fondamentaux du système ferroviaire transeuropéen conventionnel ne s'appliquent plus. |
(15) |
La STI relative aux «Applications télématiques au service du fret» est de nature fonctionnelle. Par conséquent, les dispositions énoncées dans la STI s'adresseront principalement aux intervenants sur le marché. Un règlement destiné à un groupe bien ciblé d'intervenants est plus utile qu'une décision adressée aux États membres aux fins de la mise en œuvre des dispositions de la STI. |
(16) |
Les dispositions du présent règlement sont conformes à l'avis du comité institué par la directive 96/48/CE, |
A ARRÊTÉ LE PRÉSENT RÈGLEMENT:
Article premier
La spécification technique d'interopérabilité (ci-après dénommée «STI») relative au sous-système «Applications télématiques au service du fret» du réseau ferroviaire conventionnel visée à l'article 6, paragraphe 1, de la directive 2001/16/CE est définie dans l'annexe au présent règlement.
La STI est pleinement applicable à l'infrastructure et au matériel roulant du système ferroviaire transeuropéen conventionnel définis dans l'annexe I de la directive 2001/16/CE.
Article 2
Les entreprises ferroviaires et les gestionnaires d'infrastructures contribuent en fournissant des informations fonctionnelles et techniques concernant les différentes applications télématiques pour le transport de marchandises, définies dans le chapitre 2 de l'annexe, au plus tard six mois après l'entrée en vigueur du présent règlement.
Article 3
Les organismes représentatifs du secteur ferroviaire au niveau européen définis à l'article 3, paragraphe 2, du règlement (CE) no 881/2004 élaborent un plan stratégique européen de déploiement pour la STI jointe conformément aux critères énoncés dans le chapitre 7 de l'annexe au présent règlement.
Ils transmettent ce plan stratégique aux autres États membres et à la Commission au plus tard un an à compter de la date d'entrée en vigueur du présent règlement.
Article 4
Les dispositions de la décision 2004/446/CE relatives aux paramètres fondamentaux du système ferroviaire transeuropéen conventionnel ne s'appliquent plus à compter de la date d'entrée en vigueur du présent règlement.
Article 5
Le présent règlement entre en vigueur le jour suivant celui de sa publication au Journal officiel de l'Union européenne.
Le présent règlement est obligatoire dans tous ses éléments et directement applicable dans tout État membre.
Fait à Bruxelles, le 23 décembre 2005.
Par la Commission
Jacques BARROT
Vice-président
(1) JO L 110 du 20.4.2001, p. 1. Directive modifiée par la directive 2004/50/CE (JO L 164 du 30.4.2004, p. 114), rectifiée au JO L 220 du 21.6.2004, p. 40.
(2) JO L 155 du 30.4.2004, p. 1, rectifiée au JO L 193 du 1.6.2004, p. 1.
(3) JO L 235 du 17.9.1996, p. 6. Directive modifiée en dernier lieu par la directive 2004/50/CE.
(4) JO L 164 du 30.4.2004, p. 1, rectifié au JO L 220 du 21.6.2004, p. 3.
ANNEXE
Spécification technique d'interopérabilité concernant le sous-système «Applications télématiques au service du fret» du système ferroviaire transeuropéen conventionnel
TABLE DES MATIÈRES
1. |
INTRODUCTION |
1.1. |
Domaine d'application technique |
1.2. |
Domaine d'application geographique |
1.3. |
Contenu de la presente STI |
2. |
DÉFINITION DU SOUS-SYSTÈME/CHAMP D'APPLICATION |
2.1. |
Fonctions entrant dans le champ d'application de la STI |
2.2. |
Fonctions exterieures au champ d'application de la STI |
2.3. |
Description generale du sous-systeme |
2.3.1. |
Entites impliquees |
2.3.2. |
Procedes envisages |
2.3.3. |
Remarques generales |
3. |
EXIGENCES ESSENTIELLES |
3.1. |
Respect des exigences essentielles |
3.2. |
Aspects des exigences essentielles |
3.3. |
Aspects lies aux exigences generales |
3.3.1. |
Securite |
3.3.2. |
Fiabilite et disponibilite |
3.3.3. |
Sante |
3.3.4. |
Protection de l'environnement |
3.3.5. |
Compatibilite technique |
3.4. |
Aspects specifiques au sous-systeme «Applications telematiques au service du fret» |
3.4.1. |
Compatibilite technique |
3.4.2. |
Fiabilite et disponibilite |
3.4.3. |
Sante |
3.4.4. |
Securite |
4. |
CARACTÉRISATION DU SOUS-SYSTÈME |
4.1. |
Introduction |
4.2. |
Specifications fonctionnelles et techniques du sous-systeme |
4.2.1. |
Donnees des documents de suivi |
4.2.2. |
Demande de sillon |
4.2.3. |
Preparation du train |
4.2.4. |
Prevision de circulation du train |
4.2.5. |
Informations d'interruption de service |
4.2.6. |
Localisation du train |
4.2.7. |
HEP/HAP de la cargaison |
4.2.8. |
Mouvements des wagons |
4.2.9. |
Rapports d'echanges |
4.2.10. |
Echange de donnees pour l'amelioration de la qualite |
4.2.11. |
Donnees de reference principales |
4.2.12. |
Fichiers de reference et bases de donnees |
4.2.13. |
Transmission electronique de documents |
4.2.14. |
Mise en reseau et communication |
4.3. |
Specifications fonctionnelles et techniques des interfaces |
4.3.1. |
Interfaces avec la STI relative a l'infrastructure |
4.3.2. |
Interfaces avec la STI «Controle-commande et signalisation» |
4.3.3. |
Interfaces avec le sous-systeme «Materiel roulant» |
4.3.4. |
Interfaces avec la STI «Exploitation et gestion du trafic» |
4.4. |
Regles d'exploitation |
4.4.1. |
Qualite des donnees |
4.4.2. |
Gestion du repertoire central |
4.5. |
Regles de maintenance |
4.6. |
Qualifications professionnelles |
4.7. |
Conditions de sante et de securite |
4.8. |
Registres de l'infrastructure et du materiel roulant |
5. |
CONSTITUANTS D'INTEROPÉRABILITÉ |
5.1. |
Definition |
5.2. |
Liste des constituants |
5.3. |
Performances et specifications des constituants |
6. |
ÉVALUATION DE LA CONFORMITÉ ET/OU DE L'APTITUDE À L'EMPLOI DES CONSTITUANTS ET VÉRIFICATION DU SOUS-SYSTÈME |
6.1. |
Constituants d'interoperabilite |
6.1.1. |
Procedures d'evaluation |
6.1.2. |
Module |
6.2. |
Sous-systeme «Applications telematiques au service du fret» |
7. |
MISE EN ŒUVRE |
7.1. |
Modalites d'application de la presente STI |
7.1.1. |
Introduction |
7.1.2. |
Plan de deploiement strategique europeen (SEDP) |
7.1.3. |
Modalites de mise en œuvre |
7.2. |
Strategie de transition |
7.3. |
Gestion des modifications |
7.3.1. |
Introduction |
7.3.2. |
Lignes de base |
7.3.3. |
Diffusion des lignes de base |
7.3.4. |
Conception de nouvelles lignes de base |
7.3.5. |
Gestion des modifications — conditions requises |
7.3.6. |
Plan de gestion de la configuration — conditions requises |
7.4. |
Cas specifiques |
7.4.1. |
Introduction |
7.4.2. |
Liste des cas specifiques |
ANNEXE A: |
LISTE DES DOCUMENTS D'ACCOMPAGNEMENT |
ANNEXE B: |
GLOSSAIRE |
TABLEAUX:
Tableau 1: |
Demande de sillon |
Tableau 2: |
Annulation d'un sillon par l'EF |
Tableau 3: |
Annulation d'un sillon par le GI |
Tableau 4: |
Accusé de réception |
Tableau 5: |
Préparation du train |
Système ferroviaire transeuropéen conventionnel
Spécification technique d'interopérabilité Sous-système «Applications télématiques au service du fret»
1. INTRODUCTION
1.1. Domaine d'application technique
La présente spécification technique d'interopérabilité (STI) concerne le sous-système «Applications télématiques au service du fret», cité dans la liste du point 1, paragraphe b, de l'annexe II de la directive 2001/16/CE.
L'exploitation commerciale de trains, de wagons et d'unités intermodales sur le réseau ferroviaire transeuropéen nécessite un échange efficace d'informations entre les gestionnaires d'infrastructures, les entreprises ferroviaires et divers autres prestataires de services. De cette cohérence et de ces échanges dépendent le niveau des performances, la sécurité, la qualité des services et leur coût, et c'est sur eux que repose notamment l'interopérabilité du système ferroviaire transeuropéen conventionnel.
La spécification technique d'interopérabilité a également un impact sur les conditions d'utilisation du transport ferroviaire par les usagers. Le terme «usagers» désigne ici non seulement les gestionnaires d'infrastructures ou les entreprises ferroviaires, mais également tous les autres prestataires de services, tels que les constructeurs de wagons, les opérateurs de transports intermodaux et les clients.
Enfin, l'avantage de l'interopérabilité du système ferroviaire conventionnel a été pris en considération dans l'instauration des conditions favorables à une meilleure interopérabilité entre les divers modes de transport, notamment entre le transport ferroviaire conventionnel et le transport ferroviaire combiné.
Cette STI a pour objectif de garantir que les échanges d'informations sont à tout moment parfaitement adaptés à l'évolution des exigences, sur les plans qualitatif et quantitatif, de manière à ce que le processus de transport puisse autant que possible préserver sa viabilité économique et que le transport ferroviaire de fret, face à l'intense concurrence qu'il doit affronter, maintienne sa position sur le marché.
Cet objectif nécessite la construction ou la modernisation du système ferroviaire transeuropéen conventionnel en vue du transport ferroviaire conventionnel et intermodal. Ce besoin de modernisation du volet ferroviaire du système de transport se manifeste également lorsque l'on compare les points critiques (interfaces entre les divers partenaires impliqués) du transport routier de fret à ceux du transport ferroviaire, comme l'illustre la stratégie simplifiée présentée à l'annexe A, index 5, chapitre 1.1.
L'objectif final de la présente STI est de permettre la gestion des chargements en respectant les modalités de toutes ces interfaces, grâce aux échanges d'informations sur la base des directives 2001/14/CE ( (1)) et 2001/16/CE du Parlement européen et du Conseil.
Cette brève explication du domaine d'application de la STI «Applications télématiques au service du fret» du système de transport ferroviaire conventionnel permet également de la distinguer de la STI «Exploitation et gestion du trafic», qui couvre — notamment sur le plan de la sécurité — les procédures et les équipements correspondants qui permettent une exploitation cohérente des différents sous-systèmes structurels. Il s'agit en particulier de la conduite des trains et de la planification et de la gestion du trafic, qui constituent les activités principales de toute entreprise ferroviaire (EF), selon sa définition (voir le chapitre 2.3 — Description générale du sous-système).
La STI «Applications télématiques» couvre les applications au service du fret et la gestion des correspondances avec d'autres modes de transport; en d'autres termes, elle porte essentiellement sur les services de transport offerts par les entreprises ferroviaires en plus de leurs activités d'exploitation pure et simple des trains. Les aspects de la sécurité ne sont pris en considération que lorsque des données qui sont par exemple erronées ou obsolètes risquent d'avoir un impact sur la sécurité des trains.
1.2. Domaine d'application géographique
Le domaine d'application géographique de la présente STI est le système ferroviaire transeuropéen conventionnel tel qu'il est décrit à l'annexe I de la directive 2001/16/CE. Cette STI peut également s'appliquer à l'ensemble du réseau ferroviaire de transport de fret des États membres de l'UE, si ce n'est que dans ce cas, ses prescriptions ne s'appliquent pas au transport de fret en provenance ou à destination de pays tiers.
1.3. Contenu de la présente STI
Conformément à l'article 5, paragraphe 3, de la directive 2001/16/CE, la présente STI:
a) |
délimite le champ d'application visé dans le cadre du sous-système «Applications télématiques au service du fret» — Chapitre 2: Définition du sous-système/champ d'application; |
b) |
précise les exigences essentielles relatives au sous-système concerné et à son interface vis-à-vis des autres sous-systèmes — Chapitre 3: Exigences essentielles; |
c) |
définit les spécifications fonctionnelles et techniques à respecter par le sous-système et ses interfaces vis-à-vis des autres sous-systèmes — Chapitre 4: ; |
d) |
détermine les constituants d'interopérabilité et les interfaces qui font l'objet de spécifications européennes, dont les normes européennes, et qui sont nécessaires pour réaliser l'interopérabilité du système ferroviaire transeuropéen conventionnel — Chapitre 5: Constituants d'interopérabilité ; |
e) |
indique, dans chaque cas envisagé, les procédures d'évaluation de la conformité ou de l'aptitude à l'emploi. Il s'agit notamment des modules définis dans la décision 93/465/CEE du Conseil ( (2)) ou, le cas échéant, des procédures spécifiques à suivre pour évaluer soit la conformité, soit l'aptitude à l'emploi des constituants d'interopérabilité ainsi que la vérification «CE» des sous-systèmes — Chapitre 6: Évaluation de la conformité et/ou de l'aptitude à l'emploi des constituants et vérification du sous-système; |
f) |
indique la stratégie de mise en œuvre de la STI. Il faut notamment préciser les étapes à franchir pour passer progressivement de la situation existante à la situation finale, où le respect de la STI sera généralisé — Chapitre 7: Mise en œuvre; |
g) |
indique, pour le personnel concerné, les qualifications professionnelles et les conditions de santé et de sécurité au travail requises pour l'exploitation et la maintenance du sous-système visé ainsi que pour la mise en œuvre de la STI — Chapitre 4: Caractérisation du sous-système. |
En outre, conformément à l'article 5, paragraphe 5, des cas spécifiques peuvent être prévus pour cette STI, lesquels sont indiqués au point 7.4 «Cas spécifiques».
Enfin, cette STI fixe également, dans le chapitre 4 (Caractérisation du sous-système), les prescriptions d'exploitation et de maintenance relatives aux domaines d'application technique (chapitre 1.1) et géographique (chapitre 1.2).
2. DÉFINITION DU SOUS-SYSTÈME/CHAMP D'APPLICATION
2.1. Fonctions entrant dans le champ d'application de la STI
Le sous-système «Applications télématiques au service du fret» est défini au point 2.5, paragraphe b, de l'annexe II de la directive 2001/16/CE.
Il comprend notamment:
— |
les applications au service du fret, y compris les systèmes d'information (suivi en temps réel des marchandises et des trains), |
— |
les systèmes de triage et d'affectation (ce terme étant entendu au sens de la composition des trains), |
— |
les systèmes de réservation (au sens de la réservation de sillons), |
— |
la gestion des correspondances avec d'autres modes de transport et la production des documents électroniques d'accompagnement. |
2.2. Fonctions extérieures au champ d'application de la STI
Le champ d'application de la présente STI ne couvre pas les systèmes de paiement et de facturation vis-à-vis des clients, ni ceux qui sont appliqués entre les divers prestataires de services, tels que les entreprises ferroviaires ou les gestionnaires d'infrastructures. Cependant, le système sous-jacent à l'échange de données, conformément au point 4.2 «Spécifications fonctionnelles et techniques du sous-système», est conçu de manière à fournir les informations nécessaires aux paiements découlant des services de transport.
La planification des horaires à long terme n'entre pas non plus dans le champ d'application de la présente STI. Celle-ci y fera cependant référence à certains endroits dans la mesure où cette planification influe sur l'efficacité des échanges d'informations requis pour la circulation de trains.
2.3. Description générale du sous-système
2.3.1. Entités impliquées
La présente STI tient compte des prestataires de services actuels et potentiels impliqués dans le transport de fret, plus précisément dans les services suivants (liste non exhaustive):
— |
wagons, |
— |
locomotives, |
— |
conducteurs, |
— |
aiguillages et manœuvres par gravité, |
— |
vente de créneaux horaires (sillons), |
— |
gestion des cargaisons, |
— |
composition des trains, |
— |
exploitation des trains, |
— |
surveillance de la marche des trains, |
— |
commande des trains, |
— |
suivi des chargements, |
— |
révision et réparation de wagons et/ou de locomotives, |
— |
dédouanement, |
— |
exploitation de terminaux intermodaux, |
— |
gestion du transport routier. |
Certains prestataires de services sont explicitement définis dans les directives 2001/14/CE et 2001/16/CE. Ces deux textes devant être pris en considération, la présente STI s'appuie notamment sur la définition suivante (voir également l'annexe A, index 6):
«gestionnaire de l'infrastructure» (GI): tout organisme ou toute entreprise chargé notamment de l'établissement et de l'entretien de l'infrastructure ferroviaire. Ceci peut également inclure la gestion des systèmes de contrôle et de sécurité de l'infrastructure. Les fonctions de gestionnaire de l'infrastructure sur tout ou partie d'un réseau peuvent être attribuées à plusieurs organismes ou entreprises.
En se fondant sur cette définition, la présente STI considère un GI comme le prestataire de services chargé de l'attribution des sillons, de la commande et de la surveillance des trains, ainsi que des signalements relatifs aux trains et aux sillons.
Selon la directive 2001/14/CE, l'organisme ou l'entreprise auquel un GI attribue un sillon est considéré comme un «candidat»:
«candidat» toute entreprise ferroviaire agréée et/ou tout regroupement international d'entreprises ferroviaires titulaires d'une licence et, dans les États membres qui prévoient cette possibilité, d'autres personnes physiques ou morales ou entités ayant des raisons commerciales ou de service public d'acquérir des capacités de l'infrastructure pour l'exploitation d'un service ferroviaire sur leurs territoires respectifs, comme les autorités publiques visées dans le règlement (CEE) no 1191/69 et les chargeurs, les transitaires et les opérateurs de transports combinés.
«entreprise ferroviaire» une entreprise à statut privé ou public, qui a obtenu une licence conformément à la législation communautaire applicable, dont l'activité principale est la fourniture de prestations de transport de marchandises et/ou de voyageurs par chemin de fer, la traction devant obligatoirement être assurée par cette entreprise; ce terme couvre aussi les entreprises qui assurent uniquement la traction.
Sur la base de cette définition, la présente STI considère l'entreprise ferroviaire comme étant le prestataire de services pour l'exploitation des trains.
En ce qui concerne l'attribution des sillons, l'article 13 de la directive 2001/14/CE doit également être pris en considération:
«Les capacités de l'infrastructure disponibles sont réparties par le gestionnaire de l'infrastructure et ne peuvent, une fois affectées à un candidat, être transférées par le bénéficiaire à une autre entreprise ou un autre service. Toute transaction relative aux capacités d'infrastructure est interdite et entraîne l'exclusion de l'attribution ultérieure de capacités. L'utilisation de capacités par une entreprise ferroviaire pour exercer les activités d'un candidat qui n'est pas une entreprise ferroviaire n'est pas considérée comme un transfert.»
Pour les scénarios de communication entre gestionnaires d'infrastructure et candidats dans l'exécution d'une opération de transport, seuls le GI et l'EF sont pris en considération et non tous les types de candidats, ce qui peut être pertinent pour la planification. Lors de l'exécution, la relation entre le GI et l'EF est toujours définie suivant les spécifications de la présente STI relatives aux échanges de messages et au stockage des informations. Ceci n'a aucun effet sur la définition du candidat, ni sur les possibilités d'attribution de sillons qui en résultent.
Comme on l'a déjà dit, le transport de fret implique divers services. Il peut s'agir par exemple de la fourniture de wagons. Ce service est assimilable à celui que fournit le gestionnaire d'une flotte de véhicules. S'il entre dans le cadre des activités de l'EF, cette dernière agit également en qualité de gestionnaire de flotte et peut, à ce titre, gérer ses propres wagons et/ou ceux d'un autre détenteur (un autre prestataire de services pour les wagons de fret). Les besoins de ce type de prestataire sont également pris en considération, indépendamment du fait que le gestionnaire de flotte soit une EF ou non.
La présente STI ne crée pas de nouvelles personnes morales et ne contraint aucune EF à solliciter des prestataires de services externes pour des services qu'elle offre elle-même. Cependant, elle désigne, si nécessaire, un service par le nom d'un prestataire correspondant. Si le service est fourni par une EF, celle-ci agit comme prestataire de ce service.
Dans la prise en considération des besoins du client, une des prestations consiste à organiser et à gérer la chaîne des transports conformément aux engagements pris vis-à-vis de ce client. Ce service est fourni par l'entreprise ferroviaire principale (EFP). L'EFP est le seul interlocuteur du client. Si la chaîne de transport implique plusieurs entreprises ferroviaires, l'EFP est également chargée de la coordination avec celles-ci.
Ce service peut également être exécuté par un transitaire ou par toute autre entité.
Le rôle d'une EF en tant qu'EFP dépend du type de transport concerné. En matière d'activité intermodale, la gestion des capacités des trains complets et l'établissement des feuilles de route sont assurés par un intégrateur de services intermodaux, qui pourrait être le client de l'EFP.
Il est toutefois primordial que les EF, les GI et tous les autres prestataires de services (au sens défini ci-dessus) travaillent ensemble, en coopération et/ou en accès libre, ainsi que via des échanges efficaces d'informations, afin de fournir des services intégrés aux clients.
2.3.2. Procédés envisagés
En vertu de la directive 2001/16/CE, la présente STI relative au transport ferroviaire de fret se limite, pour ce qui concerne leurs clients directs, aux GI et aux EF/EFP.
Dans le cadre des services de fret, l'activité d'une EFP débute par la réception de la lettre de voiture délivrée par son client et, par exemple, s'il s'agit de wagons, à la date et l'heure de leur mise à disposition. L'EFP élabore un plan d'acheminement préliminaire (sur la base de son expérience et/ou du contrat). Si elle a l'intention de disposer des wagons en accès libre (c'est-à-dire qu'elle exploite le train sur l'ensemble du parcours), le plan d'acheminement préliminaire est forcément définitif. Si l'EFP a l'intention de placer les marchandises dans les wagons d'un train qui dépend également d'autres EF, elle doit d'abord identifier celles auxquelles elle doit s'adresser et déterminer le moment où aura lieu l'échange entre deux EF successives. Elle prépare ensuite les demandes préliminaires de wagons séparément pour chaque EF, comme s'il s'agissait de sous-ensembles de la lettre de voiture. Les demandes de wagons sont décrites au point 4.2.1 «Données des documents de suivi».
Les EF contactées vérifient la disponibilité des capacités nécessaires à l'exploitation des wagons et à celle du sillon. Leurs réponses permettent à l'EFP d'affiner son plan d'acheminement ou de relancer sa demande — en s'adressant éventuellement à d'autres EF — jusqu'à ce que ce plan finisse par correspondre aux exigences du client.
D'une manière générale, les EF/EFP doivent au minimum pouvoir:
— |
DÉFINIR les services en mentionnant les tarifs et le temps de transit, l'offre de wagons (le cas échéant), des informations relatives aux wagons et aux unités intermodales (emplacement, état et heure d'arrivée prévue — ci-après dénommée «HAP»), le lieu de chargement des cargaisons sur des wagons vides, dans des conteneurs, etc., |
— |
FOURNIR le service défini d'une manière fiable et cohérente en utilisant les processus commerciaux courants et les systèmes connexes. Les EF, les GI et les autres prestataires de services et parties prenantes, telles que les douanes, doivent disposer de moyens informatisés d'échange de données, |
— |
ESTIMER la qualité du service fourni sur la base des paramètres définis. En d'autres termes, il s'agit de vérifier l'adéquation entre la facturation et le devis, entre le temps de transit réel et le temps prévu, entre le nombre de wagons demandés et celui fourni, et entre les HAP et les heures d'arrivée réelles, |
— |
EXPLOITER d'une manière productive la disponibilité des trains et de l'infrastructure ainsi que la capacité de la flotte en utilisant les processus commerciaux, les systèmes et les moyens d'échange de données nécessaires à la gestion des wagons/unités intermodales et à l'horaire des trains. |
En tant que candidats, les EF/EFP doivent également fournir (par la conclusion de contrats avec les GI) les sillons requis et exploiter le train sur la section du parcours qui leur incombe. Elles peuvent utiliser des sillons déjà réservés (en mode de planification) ou demander au(x) gestionnaire(s) d'infrastructure concerné(s) un sillon ad hoc pour les sections du parcours qu'elles exploitent. L'annexe A, index 5, chapitre 1.2 donne un exemple de demande de sillon.
L'attribution du sillon est en outre essentielle à la communication entre les EF et les GI pendant le transport. Elle doit toujours se fonder sur le numéro du train et du sillon que l'EF a réservé sur l'infrastructure du GI (voir aussi l'annexe A, index 5, chapitre 1.2).
Si une EF assure l'ensemble du parcours A-F (en accès libre, aucune autre EF n'étant impliquée), chaque GI concerné communique directement et uniquement avec elle. Cet «accès libre» peut être obtenu en réservant le sillon auprès d'un «guichet unique» (GU) ou, par section du parcours, directement auprès de chaque GI. La présente STI permet ces deux possibilités, comme le prévoit le point 4.2.2.1. «Demande de sillon, Remarques préliminaires».
Le dialogue entre les EF et les GI en vue d'attribuer un sillon à un train de marchandises est défini au point 4.2.2 «Demande de sillon». Cette fonction se base sur l'article 23, paragraphe 1, de la directive 2001/14/CE. Le dialogue ne couvre pas l'obtention de la licence pour une EF fournissant des services conformément à la directive 2001/13/CE du Parlement européen et du Conseil ( (3)), l'obtention de la certification visée par la directive 2001/14/CE ni les droits d'accès prévus par la directive 91/440/CEE du Conseil ( (4)).
Les échanges d'informations relatifs à la composition et à la procédure de départ des trains sont définis au point 4.2.3 «Préparation du train». Les échanges de données pendant le transport en exploitation normale sont décrits au point 4.2.4 «Prévision de circulation du train», tandis que, pour les situations exceptionnelles, les messages sont définis au point 4.2.5 «Informations d'interruption de service». Les informations relatives à la localisation des trains sont définies au point 4.2.6 «Localisation du train».Tous ces messages sont échangés entre l'EF et le GI et se fondent sur les trains.
Pour le client, l'information la plus importante est toujours l'heure d'arrivée prévue (HAP) de ses marchandises. La HAP peut être calculée à partir des échanges d'informations entre l'EFP et le GI (dans le cas d'un accès libre). Dans le cas d'une coopération entre plusieurs EF, la HAP et les heures d'échange prévues (HEP) peuvent être déterminées à partir des messages échangés entre les EF et les GI et fournis par les EF à l'EFP (point 4.2.7 «HEP/HAP de la cargaison».
Ces échanges d'informations permettent également à l'EFP de savoir, par exemple:
— |
quand les wagons sont partis du ou arrivés au dépôt ou à l'endroit défini (point 4.2.8 «Mouvements des wagons» ou |
— |
quand la responsabilité des wagons a été transférée d'une EF à l'autre dans la chaîne de transport (point 4.2.9 «Rapports d'échanges»). |
Il est possible d'obtenir diverses statistiques à partir des données échangées entre les GI et les EF et entre les EF et l'EFP, qui permettent:
— |
à moyen terme, de planifier le processus de production d'une manière plus précise et, |
— |
à plus long terme, d'effectuer des opérations de planification stratégique et des études de capacité (analyses des réseaux, définition de voies de service et de gares de triage, planification du matériel roulant), mais surtout |
— |
d'améliorer la qualité et la productivité du transport (point 4.2.10 «Échange de données pour l'amélioration de la qualité»). |
La gestion des wagons vides revêt une importance toute particulière lorsqu'il s'agit de wagons interopérables. En principe, il n'y a aucune différence entre les wagons chargés et vides sur le plan des manœuvres. Le transport de wagons vides est également fonction des demandes de wagons et, de ce fait, le gestionnaire de flotte qui en a la charge doit être considéré comme un client.
2.3.3. Remarques générales
La qualité du système d'informations dépend de la fiabilité des données qu'il contient. C'est pourquoi les données qui jouent un rôle déterminant dans l'acheminement de marchandises, d'un wagon ou d'un conteneur doivent être précises et obtenues selon un procédé économiquement rentable, qui ne nécessite de ne saisir les données dans le système qu'une seule fois.
De la sorte, les applications et les messages tels qu'ils sont définis dans la présente STI permettent d'éviter la saisie manuelle et répétée de données en donnant accès à des informations déjà enregistrées mentionnant, par exemple, les références du matériel roulant. Les exigences relatives aux données du matériel roulant sont définies au point 4.2.11 «Données de référence principales»). Les bases de données sur le matériel roulant doivent permettre d'accéder facilement aux données techniques. Sur la base de droits d'accès structurés en fonction des privilèges octroyés, leur contenu doit être accessible à l'ensemble des GI, des EF et des gestionnaires de flotte, en particulier à des fins de gestion de la flotte et de maintenance du matériel roulant. Elles doivent contenir toutes les données techniques indispensables pour le transport, telles que:
— |
l'identification du matériel roulant, |
— |
les caractéristiques techniques et de fabrication, |
— |
l'évaluation de la compatibilité avec l'infrastructure, |
— |
l'évaluation des caractéristiques du chargement, |
— |
les caractéristiques relatives au freinage, |
— |
les données de maintenance, |
— |
les caractéristiques environnementales. |
Dans le transport intermodal, à certains endroits spécifiques (appelés points de passage), non seulement le wagon peut être accroché à un autre train, mais il est également possible de déplacer l'unité intermodale d'un wagon à l'autre. Par conséquent, il ne suffit pas de travailler uniquement avec un plan d'acheminement pour les wagons; il faut aussi établir un plan d'acheminement pour les unités intermodales.
Le point 4.2.12 «Fichiers de référence et bases de données» mentionne une série de fichiers de référence et diverses bases de données, parmi lesquelles la base de données opérationnelle des wagons et des unités intermodales. Celle-ci contient des informations relatives à l'état de fonctionnement du matériel roulant, au poids, aux marchandises dangereuses, aux unités intermodales et à l'emplacement. Le point 4.2.13 «Transmission électronique de documents» définit les modalités applicables à la transmission électronique de documents.
La STI du sous-système «Applications télématiques au service du fret» définit les informations requises, qui doivent être échangées entre les différents partenaires impliqués dans une chaîne de transport, et permet la mise en place d'un processus normalisé et obligatoire d'échange de données. Elle présente également l'architecture d'une telle plate-forme de communication. Ce sujet est traité au point 4.2.14 «Mise en réseau et communication». Les éléments suivants sont pris en considération:
— |
l'interface avec le sous-système «Exploitation et gestion du trafic» du système ferroviaire transeuropéen conventionnel mentionné à l'article 5, paragraphe 3, de la directive 2001/16/CE, |
— |
les prescriptions relatives au contenu du document de référence du réseau qui sont définies à l'article 3 et à l'annexe I de la directive 2001/14/CE, |
— |
les informations disponibles sur les wagons de fret et les exigences relatives à la maintenance fixées par la STI «Matériel roulant». |
Il n'y a aucune transmission directe de données du sous-système «Applications télématiques au service du fret» vers le train, le conducteur ou des éléments du sous-système «Contrôle-commande et signalisation». Par ailleurs, le réseau de transmission physique est complètement indépendant de celui utilisé par ce sous-système. Le système ERTMS/ETSC utilise des bandes de fréquence de type GSM-R. Dans ce réseau ouvert, les spécifications de l'ETCS précisent que la sécurité est garantie par la gestion appropriée des risques posés par les réseaux ouverts du protocole Euroradio.
Les interfaces avec les sous-systèmes structurels «Matériel roulant» et «Contrôle-commande» ne s'obtiennent que via les bases de données de référence sur le matériel roulant (point 4.2.11.3 «Bases de données de référence du matériel roulant»), qui sont gérées par les détenteurs. Celles avec les sous-systèmes «Infrastructures», «Contrôle-commande» et «Énergie» sont fournies par le GI avec la définition du sillon (point 4.2.2.3), qui mentionne en outre les données d'infrastructure relatives au train, et avec les restrictions relatives à l'utilisation des infrastructures (point 4.2.11.2 «Bases de données d'avis de restriction d'infrastructure»).
3. EXIGENCES ESSENTIELLES
3.1. Respect des exigences essentielles
L'article 4, paragraphe 1, de la directive 2001/16/CE stipule que le système ferroviaire transeuropéen conventionnel, ses sous-systèmes et leurs constituants d'interopérabilité doivent satisfaire aux exigences essentielles énoncées en termes généraux à l'annexe III de la directive.
Dans les limites de cette STI, le respect des spécifications décrites dans le chapitre 4 (Caractérisation du sous-système) garantira automatiquement celui des exigences essentielles à prendre en considération au niveau du sous-système, citées dans le chapitre 3.
3.2. Aspects des exigences essentielles
Les exigences essentielles portent sur:
— |
la sécurité, |
— |
la fiabilité et la disponibilité, |
— |
la santé, |
— |
la protection de l'environnement, |
— |
la compatibilité technique. |
Selon la directive 2001/16/CE, les exigences essentielles peuvent s'appliquer, en règle générale, à l'ensemble du système ferroviaire transeuropéen conventionnel ou porter spécifiquement sur ses sous-systèmes et leurs constituants.
3.3. Aspects liés aux exigences générales
La pertinence des exigences générales dans le cas du sous-système «Applications télématiques au service du fret» est déterminée comme suit.
3.3.1. Sécurité
L'annexe III de la directive 2001/16/CE stipule que le sous-système «Applications télématiques» est soumis aux exigences essentielles de sécurité décrites ci-après.
— |
Exigence essentielle 1.1.1 de l'annexe III de la directive 2001/16/CE «La conception, la construction ou la fabrication, la maintenance et la surveillance des composants critiques pour la sécurité et, plus particulièrement, des éléments participant à la circulation des trains doivent garantir la sécurité au niveau correspondant aux objectifs fixés sur le réseau, y compris dans les situations dégradées spécifiées.» Cette exigence essentielle ne concerne pas le sous-système «Applications télématiques». |
— |
Exigence essentielle 1.1.2 de l'annexe III de la directive 2001/16/CE «Les paramètres intervenant dans le contact roue/rail doivent respecter les critères de stabilité de roulement nécessaires pour garantir une circulation en toute sécurité à la vitesse maximale autorisée.» Cette exigence essentielle ne concerne pas le sous-système «Applications télématiques». |
— |
Exigence essentielle 1.1.3 de l'annexe III de la directive 2001/16/CE «Les composants utilisés doivent résister aux sollicitations normales ou exceptionnelles spécifiées pendant leur durée de service. Leurs défaillances fortuites doivent être limitées dans leurs conséquences sur la sécurité par des moyens appropriés.» Cette exigence essentielle ne concerne pas le sous-système «Applications télématiques». |
— |
Exigence essentielle 1.1.4 de l'annexe III de la directive 2001/16/CE «La conception des installations fixes et des matériels roulants ainsi que le choix des matériaux utilisés doivent viser à limiter la production, la propagation et les effets du feu et des fumées en cas d'incendie.» Cette exigence essentielle ne concerne pas le sous-système «Applications télématiques». |
— |
Exigence essentielle 1.1.5 de l'annexe III de la directive 2001/16/CE «Les dispositifs destinés à être manœuvrés par les usagers doivent être conçus de façon à ne pas compromettre l'exploitation sûre des dispositifs ou la santé et la sécurité des usagers en cas d'utilisation prévisible non conforme aux instructions affichées.» Cette exigence essentielle ne concerne pas le sous-système «Applications télématiques». |
3.3.2. Fiabilité et disponibilité
«La surveillance et la maintenance des éléments fixes ou mobiles participant à la circulation des trains doivent être organisées, menées et quantifiées de manière à maintenir leur fonction dans les conditions prévues.»
Cette exigence essentielle est abordée dans les point suivants:
|
point 4.2.11: Données de référence principales, |
|
point 4.2.12: Fichiers de référence et bases de données, |
|
point 4.2.14: Mise en réseau et communication. |
3.3.3. Santé
— |
Exigence essentielle 1.3.1 de l'annexe III de la directive 2001/16/CE «Les matériaux susceptibles, dans leur mode d'utilisation, de mettre en danger la santé des personnes y ayant accès ne doivent pas être utilisés dans les trains et les infrastructures ferroviaires.» Cette exigence essentielle ne concerne pas le sous-système «Applications télématiques». |
— |
Exigence essentielle 1.3.2 de l'annexe III de la directive 2001/16/CE «Le choix, la mise en œuvre et l'utilisation de ces matériaux doivent viser à limiter l'émission de fumées ou de gaz nocifs et dangereux, notamment en cas d'incendie.» Cette exigence essentielle ne concerne pas le sous-système «Applications télématiques». |
3.3.4. Protection de l'environnement
— |
Exigence essentielle 1.4.1 de l'annexe III de la directive 2001/16/CE «Les incidences sur l'environnement de l'implantation et de l'exploitation du système ferroviaire transeuropéen conventionnel doivent être évaluées et prises en compte lors de la conception de ce système selon les dispositions communautaires en vigueur.» Cette exigence essentielle ne concerne pas le sous-système «Applications télématiques». |
— |
Exigence essentielle 1.4.2 de l'annexe III de la directive 2001/16/CE «Les matériaux utilisés dans les trains et dans les infrastructures doivent éviter l'émission de fumées ou de gaz nocifs et dangereux pour l'environnement, notamment en cas d'incendie.» Cette exigence essentielle ne concerne pas le sous-système «Applications télématiques». |
— |
Exigence essentielle 1.4.3 de l'annexe III de la directive 2001/16/CE «Les matériels roulants et les systèmes d'alimentation en énergie doivent être conçus et réalisés pour être compatibles, en matière électromagnétique, avec les installations, les équipements et les réseaux publics ou privés avec lesquels ils risquent d'interférer.» Cette exigence essentielle ne concerne pas le sous-système «Applications télématiques». |
— |
Exigence essentielle 1.4.4 de l'annexe III de la directive 2001/16/CE «L'exploitation du système ferroviaire transeuropéen conventionnel doit respecter les niveaux réglementaires en matière de nuisances sonores.» Cette exigence essentielle ne concerne pas le sous-système «Applications télématiques». |
— |
Exigence essentielle 1.4.5 de l'annexe III de la directive 2001/16/CE «L'exploitation du système ferroviaire transeuropéen conventionnel ne doit pas être à l'origine, dans le sol, d'un niveau de vibrations inadmissible pour les activités et le milieu traversé proches des infrastructures et en état normal d'entretien.» Cette exigence essentielle ne concerne pas le sous-système «Applications télématiques». |
3.3.5. Compatibilité technique
— |
Exigence essentielle 1.5 de l'annexe III de la directive 2001/16/CE «Les caractéristiques techniques des infrastructures et des installations fixes doivent être compatibles entre elles et avec celles des trains appelés à circuler sur le système ferroviaire transeuropéen conventionnel. Lorsque le respect de ces caractéristiques se révèle difficile dans certaines parties du réseau, des solutions temporaires, garantissant la compatibilité future, pourraient être mises en œuvre.» Cette exigence essentielle ne concerne pas le sous-système «Applications télématiques». |
3.4. Aspects spécifiques au sous-système «Applications télématiques au service du fret»
3.4.1. Compatibilité technique
— |
Exigence essentielle 2.7.1 de l'annexe III de la directive 2001/16/CE «Les exigences essentielles dans le domaine des applications télématiques garantissant une qualité de service minimale aux voyageurs et aux clients du secteur marchandises concernent plus particulièrement la compatibilité technique. Pour ces applications, il faut veiller à ce que:
Cette exigence essentielle est abordée en particulier dans les points suivants:
|
3.4.2. Fiabilité et disponibilité
— |
Exigence essentielle 2.7.2 de l'annexe III de la directive 2001/16/CE «Les modes d'utilisation, de gestion, de mise à jour et de maintenance de ces bases de données, logiciels et protocoles de communication des données doivent garantir l'efficacité de ces systèmes et la qualité du service.» Cette exigence essentielle est abordée en particulier dans les points suivants:
Toutefois, cette exigence essentielle, et en particulier la méthode utilisée pour garantir l'efficacité de ces applications télématiques et la qualité du service, constituent la base de la STI dans son ensemble et ne sont pas limitées aux chapitres mentionnés ci-dessus. |
3.4.3. Santé
— |
Exigence essentielle 2.7.3 de l'annexe III de la directive 2001/16/CE «Les interfaces de ces systèmes avec les utilisateurs doivent respecter les règles minimales en matière ergonomique et de protection de la santé.» Cette STI ne fixe pas d'exigences supplémentaires par rapport aux législations nationales et européenne relatives aux règles minimales en la matière en ce qui concerne l'interface entre ces applications télématiques et les utilisateurs. |
3.4.4. Sécurité
— |
Exigence essentielle 2.7.4 de l'annexe III de la directive 2001/16/CE «Des niveaux d'intégrité et de fiabilité suffisants doivent être assurés pour le stockage ou la transmission d'informations liées à la sécurité.» Cette exigence essentielle est abordée en particulier dans les points suivants:
|
4. CARACTÉRISATION DU SOUS-SYSTÈME
4.1. Introduction
Le système ferroviaire transeuropéen conventionnel, auquel s'applique la directive 2001/16/CE et dont fait partie le sous-système «Applications télématiques», est un système intégré dont il faut vérifier la cohérence, en particulier au niveau des spécifications du sous-système, de ses interfaces vis-à-vis du système dans lequel il s'intègre, ainsi que des règles d'exploitation et de maintenance.
Compte tenu de toutes les exigences essentielles applicables, le sous-système «Applications télématiques au service du fret» est caractérisé par les éléments ci-après.
4.2. Spécifications fonctionnelles et techniques du sous-système
À la lumière des exigences essentielles indiquées au chapitre 3 (Exigences essentielles), les spécifications fonctionnelles et techniques du sous-système sont les suivantes:
— |
les données des documents de suivi, |
— |
la demande de sillon, |
— |
la préparation du train, |
— |
la prévision de circulation du train, |
— |
les informations d'interruption de service, |
— |
la localisation du train, |
— |
les HEP/HAP des wagons/unités intermodales, |
— |
les mouvements des wagons, |
— |
les rapports d'échange, |
— |
les échanges de données pour l'amélioration de la qualité, |
— |
les données de référence principales, |
— |
les fichiers de référence et les bases de données, |
— |
la transmission électronique de documents, |
— |
la mise en réseau et la communication. |
Les spécifications détaillées sont décrites ci-dessous. On trouvera de plus amples informations ainsi que les formats des messages à l'annexe A, index 1.
Remarques générales sur la structure des messages
Les messages sont structurés en deux ensembles de données:
— |
les données de contrôle: voir les explications ci-dessous, |
— |
les informations fournies: informations relatives à la demande. |
Les données de contrôle sont les éléments suivants:
— |
L'état: l'état du message peut être:
|
— |
Les références du message:
|
— |
La référence apparentée, seulement si le message est la réponse à un message précédent (identique à l'objet du message reçu):
|
— |
L'expéditeur du message. |
— |
Le destinataire du message. |
Les chapitres suivants concernent essentiellement l'état «nouveau message». Le point 4.2.2 «Demande de sillon» se réfère également à l'état «suppression» en ce qui concerne le message de demande de sillon.
4.2.1. Données des documents de suivi
4.2.1.1. Lettre de voiture du client
La lettre de voiture doit être envoyée par le client à l'EFP. Elle doit contenir toutes les informations nécessaires au transport du fret entre l'expéditeur et le destinataire. L'EFP doit compléter ces données par des informations supplémentaires. Tous ces renseignements sont énumérés dans le tableau de l'annexe A, index 3, qui indique, dans la colonne «Données des documents de suivi», leur caractère facultatif ou obligatoire et s'ils doivent être fournis par l'expéditeur ou être ajoutés par l'EFP.
En accès libre, l'EFP qui est en relation avec le client dispose de toutes les informations une fois que les données supplémentaires sont disponibles. Aucun échange de messages avec d'autres EF n'est nécessaire. Ces informations servent également de base à la rédaction d'une demande de sillon à court terme, si celle-ci est nécessaire à l'exécution de la lettre de voiture.
Les messages suivants ne sont pas utilisés en accès libre. Leur contenu peut aussi servir de base aux demandes de sillon à court terme, si elles sont nécessaires à l'exécution de la lettre de voiture.
4.2.1.2. Demandes de wagons
La demande de wagons constitue avant tout un sous-ensemble des informations contenues dans la lettre de voiture. Elle doit être transmise aux EF impliquées dans la chaîne de transport, car elle peut servir aux demandes de sillon ad hoc (point 4.2.2 «Demande de sillon»). La demande de wagons doit contenir les informations nécessaires aux EF pour assurer le transport sur la section qui leur incombe, jusqu'au transfert de la responsabilité de la cargaison à l'EF suivante. Par conséquent, son contenu dépend du travail à effectuer par l'entreprise ferroviaire: enlèvement, transit ou livraison.
— |
Demande de wagons pour l'EF chargée de l'enlèvement des marchandises (EFR) |
— |
Demande de wagons pour l'EF chargée du transit (EFT) |
— |
Demande de wagons pour l'EF chargée de la livraison (EFL) |
Les informations qui doivent figurer dans les demandes de wagons en fonction du rôle de l'EF sont détaillées à l'annexe A, index 3, qui indique également leur caractère obligatoire ou facultatif. Les formats précis de ces messages sont définis à l'annexe A, index 1.
Les demandes de wagons contiennent essentiellement des informations sur les éléments suivants:
— |
l'expéditeur et le destinataire, |
— |
l'acheminement, |
— |
l'identification du fret, |
— |
le wagon, |
— |
le lieu, la date et l'heure. |
Certaines informations de la lettre de voiture doivent également être accessibles à tous les partenaires de la chaîne de transport (GI, détenteur, etc.). Elles portent sur les wagons et ont trait aux éléments suivants:
— |
le poids du chargement (poids brut), |
— |
le numéro de code NC/SH, |
— |
des informations relatives aux marchandises dangereuses, |
— |
l'unité de transport. |
4.2.2. Demande de sillon
4.2.2.1. Remarques préliminaires
Planification à long terme
Le sillon définit les données demandées, acceptées et actualisées qui doivent être enregistrées ainsi que les caractéristiques du train pour chaque segment de ce sillon. Les informations qui doivent être mises à la disposition du gestionnaire de l'infrastructure sont décrites ci-après. Pour une description plus détaillée, voir l'annexe A, index 4.
Ces informations doivent être mises à jour lors de chaque modification.
Les principales données relatives au sillon sont les suivantes:
— |
l'identification du sillon (numéro du sillon). Il peut s'agir soit de l'utilisation prévue de l'infrastructure sur une section donnée de l'itinéraire, soit de l'itinéraire réel d'un train sur une voie précise de l'itinéraire. La nature exacte du sillon dépend des procédés utilisés par le GI concerné, |
— |
le point de départ du sillon, c'est-à-dire le lieu où il commence ainsi que la date et l'heure du départ du train sur ce sillon, |
— |
la destination du sillon, c'est-à-dire le lieu où il se termine ainsi que la date et l'heure d'arrivée prévues du train, |
— |
la description de la section du parcours, c'est-à-dire les données fournies par le GI pour chaque section acceptée, autrement dit entre le point de départ et le premier arrêt intermédiaire, puis entre les autres arrêts intermédiaires et, enfin, entre le dernier arrêt intermédiaire et la fin du parcours accepté. Cette description peut comprendre:
|
Le contrat relatif au sillon à suivre: avant l'exploitation du train, la section du parcours doit être mise à jour et complétée par des valeurs actualisées. Le mode d'exécution est tout à fait indépendant du mode de planification.
Demande de sillon à court terme
Pour faire face aux situations exceptionnelles pendant l'exploitation du train ou à des demandes de transport à court terme, une entreprise ferroviaire doit avoir la possibilité d'obtenir un sillon ad hoc sur le réseau.
Dans le premier cas, il est nécessaire de prendre des mesures immédiates permettant de connaître la composition réelle du train sur la base de la liste fournie.
Dans le second cas, l'entreprise ferroviaire doit fournir au gestionnaire de l'infrastructure toutes les informations nécessaires concernant la date, l'heure et le lieu de circulation du train ainsi que ses caractéristiques physiques dans la mesure où elles interagissent avec l'infrastructure. La plupart de ces données figurent dans la lettre de voiture, plus précisément dans les demandes de wagons.
L'accord relatif au sillon dans le cas de l'exploitation d'un train à brève échéance doit faire l'objet d'un dialogue entre toutes les EF et tous les GI concernés, même si leur contribution peut varier en fonction du processus de recherche de sillon. L'article 13 de la directive 2001/14/CE distingue principalement deux scénarios pour le transport de fret sur les infrastructures de plusieurs GI (voir aussi l'annexe A, index 5, chapitre 1.3).
— |
Scénario A: l'EF contacte tous les GI concernés, soit directement (cas A) soit par l'intermédiaire du guichet unique (cas B), afin d'organiser les sillons pour l'ensemble du parcours. Dans ce cas, l'EF doit également exploiter le train sur l'ensemble du parcours. |
— |
Scénario B: chaque EF concernée par le parcours contacte les GI locaux directement ou par l'intermédiaire du guichet unique afin de demander un sillon pour la section sur laquelle elle exploite le train. |
Remarque: comme cela a déjà été précisé au chapitre 2 (Définition du sous-système/champ d'application), pendant le trajet, le GI communiquera toujours avec l'EF qui a réservé le sillon. Par conséquent, la «propriété du sillon» est importante pour les échanges de messages pendant l'exploitation du train.
Dans les deux cas, la procédure de réservation d'un sillon à court terme suit le mode de dialogue entre l'EF et le GI concernés décrit ci-après.
Le tableau ci-dessous présente les messages utilisés dans le dialogue relatif à la demande de sillon.
Tableau 1
Demande de sillon
Message |
Explication |
Messages utilisés dans le dialogue relatif à la demande de sillon |
|
Demande de sillon |
Ce message doit être envoyé par l'EF au(x) GI concerné(s) pour une demande de sillon à court terme. |
Détails du sillon |
Ce message doit être envoyé par le(s) GI à l'EF pour confirmer les détails du sillon, en réponse à la demande. Il doit comprendre les données éventuellement modifiées ou, si le GI ne peut pas répondre positivement à la demande de sillon, indiquer la mention «aucune possibilité disponible». |
Sillon confirmé |
Ce message doit être envoyé par l'EF au GI pour confirmer l'acceptation des «détails du sillon» envoyés par le GI en réponse à la demande initiale de l'EF. |
Détails du sillon refusés |
Ce message doit être envoyé par l'EF au GI si elle refuse les «détails du sillon» envoyés par le GI en réponse à sa demande, si elle ne peut accepter certaines données modifiées. |
Le dialogue se termine par le message d'acceptation du sillon envoyé par l'EF ou par la suppression de la demande de sillon (pour en savoir plus sur le message de demande de sillon avec l'état «suppression», voir le point 4.2 «Spécifications fonctionnelles et techniques du sous-système» — Remarques générales sur la structure des messages). Un message de refus des détails du sillon doit toujours être suivi d'une nouvelle proposition du GI (nouveau message «détails du sillon»). Si le GI ne peut répondre positivement à la demande, il doit envoyer ce nouveau message avec l'indication «aucune possibilité disponible», qui termine le dialogue avec l'EF.
Que le sillon ait été réservé lors d'une planification à long terme ou à court terme, l'EF doit toujours avoir la possibilité d'annuler sa réservation. Pour annuler un sillon réservé, le message suivant doit être utilisé.
Tableau 2
Annulation d'un sillon par l'EF
Message |
Explication |
Message d'annulation d'un sillon réservé par l'EF |
|
Sillon annulé |
Notification transmise par l'EF au GI pour annuler le sillon réservé ou une partie de celui-ci |
Une fois que l'accord d'attribution du sillon est conclu, l'EF peut s'attendre à ce que le sillon réservé soit toujours disponible. Par conséquent, si un imprévu survient qui rend le sillon réservé indisponible, le GI doit en informer l'EF dès qu'il en a connaissance. La cause peut être, par exemple, une interruption du sillon. Elle peut survenir à tout moment entre la signature du contrat et le départ du train. Le GI est obligé d'envoyer une proposition de remplacement en même temps que la notification d'indisponibilité du sillon. Si cela n'est pas possible, il doit envoyer sa proposition dans les meilleurs délais. Le message «sillon non disponible» ouvre un nouveau dialogue visant à conclure un nouvel accord, à l'initiative du GI.
Messages utilisés dans le dialogue d'annulation d'un sillon réservé, à l'initiative du GI
Tableau 3
Annulation d'un sillon par le GI
Message |
Explication |
Messages utilisés dans le processus d'annulation du sillon, à l'initiative du GI |
|
Sillon non disponible |
Notification transmise par le GI à l'EF pour indiquer que le sillon réservé n'est pas disponible |
Détails du sillon |
Ce message doit être envoyé par le(s) GI à l'EF afin de proposer un sillon de remplacement après la notification indiquant l'indisponibilité du sillon. |
Sillon confirmé |
Ce message doit être envoyé par l'EF au GI pour signifier son acceptation du sillon proposé dans le message «sillon non disponible». |
Détails du sillon refusés |
Ce message doit être envoyé par l'EF au GI lorsqu'elle n'accepte pas la proposition transmise par celui-ci dans le message «sillon non disponible». Dans ce cas, le GI doit envoyer une nouvelle proposition. Ce dialogue se termine par le message de l'EF indiquant «sillon annulé» en réponse au message du GI «sillon non disponible». |
En général, si le destinataire d'une demande ou d'une consultation ne peut répondre en temps réel, il doit en informer l'expéditeur du message (par exemple lorsque le message «détails du sillon» ne peut pas être envoyé immédiatement en réponse à une demande de sillon). Cette démarche doit être effectuée en utilisant le message ci-dessous.
Tableau 4
Accusé de réception
Message |
Explication |
Ce message a une validité générale |
|
Accusé de réception |
Ce message doit être envoyé par le destinataire du message à l'expéditeur lorsque la réponse ne peut pas être fournie dans le délai précisé au chapitre 4.4 (Règles d'exploitation), section «ponctualité». |
Ces messages sont décrits sommairement dans les chapitres qui suivent. Les formats détaillés sont précisés à l'annexe A, index 1. La succession logique de ces messages est présentée dans les diagrammes de l'annexe A, index 5, chapitre 2.3.
4.2.2.2. Message de demande de sillon
Il s'agit de la demande de sillon envoyée par l'EF au GI. Elle doit mentionner:
— |
le point de départ du sillon: le lieu de départ du sillon proposé, |
— |
la date et l'heure de départ demandées, |
— |
la destination du sillon: la destination du train pour le sillon demandé, |
— |
la date et l'heure d'arrivée prévues, |
— |
la section du parcours demandée:
|
Pour rédiger sa demande de sillon, l'EF peut consulter le document de référence du réseau approprié pour vérifier si les paramètres du train prévu sont conformes à l'infrastructure. Les informations concernant notamment les marchandises dangereuses doivent également être prises en considération.
Les détenteurs des wagons doivent permettre l'accès des EF aux données techniques des véhicules.
Les EF doivent, le cas échéant, garantir l'accès aux fichiers de référence, par exemple celui des marchandises dangereuses.
4.2.2.3. Message sur les détails du sillon
Ce message est la réponse d'un GI au message de «demande de sillon» d'une EF. Si le GI ne peut répondre positivement à cette demande, il doit envoyer ce message avec l'indication «aucune possibilité disponible». S'il accepte la demande, il doit accompagner sa réponse du numéro de sillon et des mêmes données que celles présentes dans la demande de sillon, ainsi que des données éventuellement modifiées.
Lorsque le GI propose une solution de remplacement, il doit communiquer les données suivantes:
— |
le nouveau numéro de sillon, |
— |
le point de départ du sillon: le lieu de départ du sillon proposé, |
— |
la date et l'heure de départ demandées, |
— |
la destination du sillon: la destination du train pour le sillon demandé; |
— |
la date et l'heure d'arrivée prévues, |
— |
la section du parcours modifiée:
|
4.2.2.4. Message de confirmation d'acceptation du sillon
Ce message doit être envoyé par l'EF au GI pour confirmer l'acceptation du sillon proposé en réponse à sa demande initiale. Il confirme en même temps la réservation du sillon. Il doit contenir les éléments suivants:
— |
le numéro d'identification du sillon, |
— |
le point de départ du sillon: le lieu de départ du train, |
— |
la date et l'heure de départ demandées, |
— |
la destination du sillon: la destination du train pour le sillon demandé, |
— |
la date et l'heure d'arrivée prévues du train proposé, |
— |
l'indication selon laquelle l'EF accepte le sillon proposé. |
4.2.2.5. Message de refus des détails du sillon
L'EF qui refuse le sillon proposé par le GI dans le message «détails du sillon» doit lui envoyer ce message afin de l'en informer. Les principaux éléments d'information de ce message sont les suivants:
— |
le numéro d'identification du sillon, |
— |
l'indication du refus des détails du sillon. |
Les données suivantes peuvent être envoyées en complément:
— |
le point de départ du sillon: le lieu de départ du train, |
— |
la date et l'heure de départ demandées, |
— |
la destination du sillon: la destination du train pour le sillon demandé, |
— |
la date et l'heure d'arrivée prévues du train proposé. |
4.2.2.6. Message d'annulation d'un sillon
Ce message est utilisé par l'EF pour annuler un sillon qu'elle a réservé. Cet avis d'annulation (qui équivaut au type du message) doit être accompagné du numéro du sillon afin de pouvoir l'identifier clairement. Cette exigence s'applique à la réservation du sillon à long terme (mode de planification) et à court terme. Il doit préciser:
— |
le numéro d'identification du sillon, |
— |
le numéro du train (dans la mesure où le GI en a déjà connaissance), |
— |
l'indication de l'annulation du sillon réservé. |
Les données suivantes peuvent être envoyées en complément:
— |
le point de départ du sillon: le lieu de départ du train, |
— |
la date et l'heure de départ demandées, |
— |
la destination du sillon: la destination du train pour le sillon demandé, |
— |
la date et l'heure d'arrivée prévues du train proposé. |
4.2.2.7. Message d'indisponibilité d'un sillon
Dès que le GI a connaissance de l'indisponibilité d'un sillon, il doit en informer l'EF. Le message «sillon non disponible» peut être envoyé à tout moment entre la signature du contrat relatif au sillon et le départ du train. La cause de cette indisponibilité peut être, par exemple, une interruption du sillon. Ce message doit contenir les données suivantes:
— |
le numéro du sillon indisponible, |
— |
le numéro du train prévu pour le sillon annulé (dans la mesure où le GI en a déjà connaissance), |
— |
le point de départ du sillon avec la date et l'heure pour lesquelles le sillon a été réservé, |
— |
la destination du sillon avec la date et l'heure d'arrivée du train, |
— |
l'indication d'indisponibilité du sillon, |
— |
l'indication du motif de l'indisponibilité. |
Parallèlement à ce message ou dès qu'il en a la possibilité, le GI doit envoyer une proposition de remplacement sans attendre une nouvelle demande de l'EF. Cette proposition est envoyée dans le message «détails du sillon» relatif au message d'indisponibilité.
4.2.2.8. Accusé de réception
Cet accusé doit être envoyé par le destinataire du message à l'expéditeur lorsqu'il ne peut fournir sa réponse dans les délais spécifiés au point 4.4 «Règles d'exploitation». Il doit faire explicitement référence au message auquel il se rapporte (entrées dans le message apparenté, voir le point 4.2 «Spécifications fonctionnelles et techniques du sous-système» — Remarques générales sur la structure des messages) et mentionner: (niveau de la demande).
— |
Accusé de réception: indique que le destinataire a reçu le message et qu'il va agir en conséquence. |
4.2.3. Préparation du train
4.2.3.1. Remarques générales
Cette rubrique est consacrée aux messages qui doivent être échangés pendant la phase de préparation du train jusqu'à son départ. Ces messages sont décrits dans le tableau 5 ci-dessous.
Pour pouvoir préparer le train, l'EF doit avoir accès aux avis de restriction d'infrastructure, aux données techniques relatives aux wagons (point 4.2.11.3 «Bases de données de référence du matériel roulant»), aux fichiers de référence relatifs aux marchandises dangereuses et aux informations mises à jour concernant les wagons (point 4.2.12.2 «Autres bases de données» — Base de données opérationnelle des wagons et des unités intermodales). Cela s'applique à tous les wagons du train. Enfin, l'EF doit envoyer la composition du train à celles qui lui succéderont, ainsi qu'au(x) GI auprès desquels elle a réservé une section de sillon, selon les prescriptions de la STI «Exploitation et gestion du trafic» pour le rail conventionnel ou du contrat entre l'EF et le(s) GI.
Si la composition des trains est modifiée en un point donné, ce message doit à nouveau être envoyé par l'EF responsable, en mentionnant les modifications apportées.
Chaque fois que la responsabilité de la cargaison est transférée à une autre EF, par exemple, aux points de départ et d'échange, il est obligatoire de lancer le dialogue sur la procédure de démarrage entre le GI et l'EF: «Train prêt — Notification sur la circulation du train».
Les messages utilisés dans le dialogue sur la procédure de démarrage sont les suivants.
Tableau 5
Préparation du train
Message |
Explication |
||||||
Composition du train |
Ce message doit être envoyé par l'EF au GI, selon la description ci-dessus. |
||||||
|
Lorsque le GI reçoit un message de composition du train dont l'envoi par l'EF est obligatoire, il peut envoyer un des messages suivants: |
||||||
|
train accepté: |
par le GI à l'EF: ce message est facultatif, si rien d'autre n'est convenu entre le GI et l'EF; |
La préparation du train peut être achevée; |
||||
|
train non approprié: |
par le GI à l'EF: ce message peut être envoyé par le GI, si c'est lui qui constate cette inadéquation. |
Possibilités offertes à l'EF:
|
||||
Train prêt |
Ce message doit être envoyé par l'EF au GI. |
||||||
Position du train |
Ce message, envoyé par le GI à l'EF, indique avec précision le lieu et le moment où le train doit se présenter sur le réseau. Il peut être envoyé si la législation nationale le prévoit. |
||||||
Train au départ |
Ce message peut être envoyé par l'EF au GI pour confirmer le départ du train, en réponse au message «position du train». Il peut être envoyé si la législation nationale le prévoit. |
||||||
Notification sur la circulation du train |
Ce message doit être envoyé par le GI à l'EF pour confirmer l'arrivée du train sur l'infrastructure. |
Ces messages sont décrits sommairement dans les chapitres qui suivent. Les formats détaillés sont définis à l'annexe A, index 1. Leur succession logique est présentée à l'annexe A, index 5, chapitre 3.
Remarque: un message d'indisponibilité du sillon peut également survenir durant la préparation du train, étant donné qu'il peut être envoyé à tout moment entre la signature du contrat relatif au sillon et le départ du train. La procédure à suivre est décrite dans le point 4.2.2. «Demande de sillon».
4.2.3.2. Message de notification de la composition du train
Ce message doit être envoyé par l'EF à l'EF qui lui succède ainsi qu'au(x) GI si la STI «Exploitation et gestion du trafic» pour le rail conventionnel ou le contrat entre l'EF et le GI l'exigent. Si la composition du train est modifiée en cours de route, l'EF responsable doit mettre le message à jour et le transmettre à toutes les parties concernées.
Les informations qui doivent être transmises et demeurer accessibles sont les suivantes:
— |
le numéro du train et le numéro d'identification du sillon, |
— |
le point de départ du sillon, ainsi que la date et l'heure pour le sillon demandé, |
— |
la destination du sillon ainsi que la date et l'heure d'arrivée prévues du train proposé, |
— |
l'identification de la (des) locomotive(s) et leur position dans le train, |
— |
la longueur du train, son poids et sa vitesse maximale, |
— |
la composition du train avec les numéros d'identification des wagons dans leur ordre de succession, |
— |
le système de commande et de contrôle, dont le type d'équipement radio, |
— |
les informations relatives aux volumes exceptionnels, |
— |
les numéros ONU/RID relatifs aux marchandises dangereuses, |
— |
l'indication de la présence de bétail et de personnes (autres que le personnel du train), |
— |
le système de freinage à utiliser, |
— |
les données relatives aux wagons. |
Dès la réception de la composition du train, le GI peut, si le contrat entre le GI et l'EF le permet explicitement, vérifier les éléments contenus dans le message en les comparant au sillon concerné. Dans ce cas, le GI doit avoir accès aux informations sur d'éventuelles restrictions de l'infrastructure concernée, aux données techniques relatives aux wagons (point 4.2.11.3 «Bases de données de référence du matériel roulant»), aux fichiers de référence des marchandises dangereuses et aux informations mises à jour relatives aux wagons (point 4.2.12.2 «Autres bases de données» — Base de données opérationnelle des wagons et des unités intermodales). Ceci concerne tous les wagons du train. Le GI, qui gère les sillons et actualise les informations qui les concernent doit ajouter les données relatives à la composition du train aux données du sillon et du train comme le mentionne le point 4.2.2.1 «Demande de sillon» Remarques préliminaires).
4.2.3.3. Message d'acceptation du train
En fonction de l'accord contractuel entre le GI et l'EF et de la réglementation applicable, le GI peut également informer l'EF que la composition du train est acceptable pour le sillon réservé. Tel est l'objectif de ce message.
Il doit contenir essentiellement les données suivantes:
— |
les numéros du train et du sillon, |
— |
le point de départ du sillon ainsi que la date et l'heure pour le sillon demandé, |
— |
la destination du sillon ainsi que la date et l'heure d'arrivée prévues du train proposé, |
— |
l'avis d'acceptation par le GI de la composition du train pour le sillon convenu. |
4.2.3.4. Message d'inadéquation du train
Si le train ne convient pas au sillon précédemment convenu, le GI peut en informer l'EF au moyen de ce message. Dans ce cas, l'EF doit vérifier à nouveau la composition du train. Ce message doit contenir essentiellement les données suivantes:
— |
les numéros du train et du sillon, |
— |
le point de départ du sillon ainsi que la date et l'heure pour le sillon demandé, |
— |
la destination du sillon ainsi que la date et l'heure d'arrivée prévues du train proposé, |
— |
l'indication selon laquelle le train ne correspond pas au sillon attribué et, par conséquent, ne peut pas circuler, |
— |
l'indication du motif de cette inadéquation. |
4.2.3.5. Message «train prêt»
Ce message doit être envoyé par l'EF au GI pour lui indiquer que le train est prêt à accéder au réseau. Il contient principalement les données suivantes:
— |
les numéros du train et du sillon, |
— |
le point de départ du sillon ainsi que la date et l'heure pour le sillon demandé, |
— |
la destination du sillon ainsi que la date et l'heure d'arrivée prévues du train proposé, |
— |
l'indication «train prêt», qui signifie que sa préparation est achevée et qu'il est prêt à circuler, |
— |
l'identifiant du contact de commande de toutes les liaisons entre le bord et le sol, |
— |
si les dispositions contractuelles entre l'EF et le GI ne nécessitent pas l'envoi du message «position du train/train au départ», il faut préciser dans ce message l'heure et la date du départ du train, qui informent le GI de l'heure et de la date prévue de présentation du train sur le réseau. Dans le cas où l'envoi du message «position du train/train au départ» est obligatoire, ces données ne doivent pas être transmises. |
4.2.3.6. Message de notification de la position du train
Ce message peut être envoyé par le GI à l'EF en réponse au message «train prêt» et définir exactement le moment et le lieu où le train doit se présenter sur le réseau. La transmission de ce message dépend de l'accord contractuel entre l'EF et le GI. Il doit contenir principalement les données suivantes:
— |
les numéros du train et du sillon, |
— |
le point de départ des sillons ainsi que la date et l'heure pour le sillon demandé, |
— |
la destination du sillon ainsi que la date et l'heure d'arrivée prévues du train proposé, |
— |
l'identifiant de la voie, qui informe l'EF de la voie sur laquelle le train doit se présenter, |
— |
la date et l'heure du départ du train, qui informe l'EF de la date et de l'heure précises à laquelle le train doit se présenter sur le réseau, |
— |
l'identifiant du contact de commande. |
4.2.3.7. Message «train au départ»
Ce message peut être envoyé par l'EF au GI lorsqu'elle a reçu le message «position du train» de ce dernier, afin d'indiquer que le train a commencé son parcours. Il doit mentionner l'identifiant auquel il se rapporte ainsi que l'indication suivante:
— |
train au départ: date et heure du départ du train |
4.2.3.8. Notification sur la circulation du train
Dès que le train est présent sur l'infrastructure du GI, autrement dit qu'il a quitté la gare de départ, le GI envoie ce message à l'EF qui a réservé le sillon. Ce message est décrit au point 4.2.4 «Prévision de circulation du train».
4.2.4. Prévision de circulation du train
4.2.4.1. Remarques générales
Cette rubrique décrit les messages qui doivent être envoyés pendant l'exploitation normale du train sans aucune interruption.
Les messages concernés sont:
|
la prévision de circulation du train, |
|
la notification sur la circulation du train. |
Cet échange d'informations s'effectue toujours entre les GI responsables et les EF qui ont réservé le sillon emprunté par le train. En mode d'accès libre, qui implique que les sillons de l'ensemble du parcours sont réservés par une seule EF (qui exploite également le train sur tout le parcours), tous les messages sont envoyés à celle-ci. Ceci s'applique également si les sillons du parcours sont réservés par une seule EF par l'intermédiaire du guichet unique.
Dans la suite de ce document, on distinguera les scénarios suivants en fonction des diverses relations de communication entre les EF et les GI et suivant les possibilités de réservation de sillon présentées au point 4.2.2.1 «Demande de sillon Remarques préliminaires» (scénarios A, B).
— |
Train approchant un point de transfert entre le GI no 1 et le GI no 2 qui lui succède |
On suppose que le point de transfert n'est pas également un point d'échange (scénario B uniquement) ni un point de manœuvre. Il est inscrit sur les sillons réservés par l'EF, qui a déjà transmis la composition du train au GI no 2 simultanément à l'envoi de ce message au GI no 1.
Après que le train a quitté son point de départ ( (5)), le GI no 1 doit envoyer un message de prévision de circulation du train au GI no 2 en indiquant l'heure de transfert prévue (HTP). Ce message est simultanément transmis à l'EF.
Lorsque le train quitte l'infrastructure du GI no 1 au point de transfert, ce GI envoie à l'EF qui a réservé le sillon une notification sur la circulation du train, qui mentionne la durée réelle du transfert au niveau de ce point.
Lorsque le train arrive sur l'infrastructure du GI no 2 au point de transfert, ce GI envoie à l'EF qui a réservé le sillon une notification sur la circulation du train, qui mentionne la durée réelle du transfert au niveau de ce point.
— |
Train approchant un point d'échange entre l'EF no 1 et l'EF no 2 (scénario B uniquement) |
Dans le contrat relatif au sillon, le point d'échange doit toujours être défini comme un point d'observation. (Les HAPT au niveau des points d'observation seront générées par les GI conformément au contrat qui les lie aux EF.)
Une fois que le train a quitté le point d'observation précédent, le GI responsable envoie à l'EF qui a réservé le sillon (par exemple l'EF no 1) un message de prévision de circulation du train mentionnant la HAPT à ce point d'échange. L'EF no 1 transmet ce message à l'EF qui lui succède (par exemple l'EF no 2) et qui est censée prendre le train en charge. Ce message est aussi envoyé, le cas échéant, à l'entreprise ferroviaire principale (EFP) si le contrat de coopération entre les deux EF le prévoit.
Si le point d'échange est également un point de transfert (par exemple entre le GI no 1 et le GI no 2), le GI no 1 envoie déjà le message de prévision de circulation du train au GI no 2 dès que le convoi a quitté le point de départ ou le point d'échange précédent, en mentionnant l'heure de transfert prévue (HTP). Ce message est également envoyé à l'EF qui a réservé le sillon, par exemple l'EF no 1. Pour celle-ci, la HTP correspond à la HAPT au point d'échange. L'EF no 1 transmet ce message à l'EF no 2 et à l'éventuelle EFP si le contrat de coopération entre les deux EF le prévoit.
À l'arrivée du train à un point d'échange, le GI doit envoyer à l'EF qui a réservé le sillon, par exemple l'EF no 1, une notification sur la circulation du train, qui mentionne l'heure d'arrivée réelle à ce point.
Avant que le train ne quitte le point d'échange, l'EF no 2 doit envoyer au GI qui lui a attribué le sillon un nouveau message de composition du train et suivre la procédure de départ définie au point 4.2.3 Préparation du train —
— |
Train approchant un point de manœuvre d'une EF (scénario A) |
Dans le contrat relatif au sillon, le point de manœuvre doit toujours être défini comme un point d'observation.
Le GI responsable doit uniquement envoyer un message de prévision de circulation du train mentionnant la HAPT si le contrat qu'il a conclu avec l'EF le prévoit.
Si le point de manœuvre est également un point de transfert (par exemple entre le GI no 1 et le GI no 2), le GI no 1 doit envoyer le message de prévision de circulation du train au GI no 2 dès que le convoi a quitté le point de départ ou le point d'échange précédent, en mentionnant l'heure de transfert prévue (HTP). Ce message est également transmis à l'EF. Pour celle-ci, la HTP correspond à la HAPT au point de manœuvre.
À l'arrivée du train au point de manœuvre, le GI doit envoyer à l'EF une notification sur la circulation du train avec l'heure d'arrivée réelle à ce point.
Avant que le train ne quitte le point de manœuvre, l'EF et le GI doivent appliquer la procédure de départ définie au point 4.2.3 Préparation du train —
— |
Arrivée du train à destination |
Lorsque le train arrive à sa destination, le GI responsable envoie à l'EF qui a réservé le sillon un message de notification sur la circulation du train, qui mentionne son heure d'arrivée réelle.
Remarque: il se peut que le contrat d'attribution du sillon définisse d'autres points qui nécessitent des messages de prévision de circulation du train avec la HAPT et de notification sur la circulation du train mentionnant l'heure d'arrivée réelle. Le GI responsable envoie ces messages conformément aux dispositions du contrat. L'évaluation et le traitement ultérieurs de ces HTP et HAPT sont décrits aux points 4.2.7 «HEP/HAP de la cargaison» à 4.2.9 «Rapports d'échanges».
Dans les chapitres qui suivent, seules les données principales des messages de prévision de circulation du train et de notification sur la circulation du train sont décrites. Les formats détaillés sont définis à l'annexe 1, index 1. La succession logique de ces échanges de messages en fonction des différents scénarios de communication est présentée à l'annexe A, index 5, chapitre 4. Il faut remarquer qu'en ce qui concerne la communication entre l'EF et les GI à propos de la circulation du train, les deux options offertes par la scénario A concernant la demande de sillon, à savoir les cas A et B (voir le point 4.2.2.1 «Demande de sillon» — Remarques préliminaires), sont identiques, étant donné que, dans les deux cas, les GI ne sont en contact qu'avec une seule EF, chargée de l'ensemble du parcours et de la nouvelle composition du train aux points de manœuvre.
4.2.4.2. Message de prévision de circulation du train
Ce message doit être envoyé par le GI pour les points de transfert, les points d'échange et la destination du train, comme le définit le point 4.2.4.1 «Prévision de circulation du train — Remarques générales».
Le GI doit également envoyer ce message à l'EF pour d'autres points d'observation (par exemple des points de manœuvre), selon le contrat conclu entre les deux parties.
Ce message doit contenir les principaux éléments d'information suivants:
— |
les numéros du train et du sillon, |
— |
la date et l'heure du départ prévues sur le site du GI (ou l'heure prévue de transfert au GI suivant), |
— |
l'identification du point d'observation, |
— |
la date et l'heure prévues au point d'observation. |
4.2.4.3. Message de notification sur la circulation du train
Ce message doit être envoyé:
— |
au départ du train du point d'origine et à son arrivée à destination, |
— |
à l'arrivée et au départ du train aux points de transfert, d'échange et d'observation convenus sur la base du contrat (par exemple aux points de manœuvre). Ce message doit contenir les principaux éléments d'information suivants:
|
4.2.5. Informations d'interruption de service
4.2.5.1. Remarques générales
Lorsque l'EF est avertie d'une interruption de service pendant l'exploitation du train dont elle est responsable, elle doit en informer immédiatement le GI concerné (pas par message électronique, mais par un message vocal du conducteur, par exemple. Si nécessaire, l'EF met à jour la base de données opérationnelle des wagons et des unités intermodales. De même, le GI met à jour les données de l'infrastructure dans la base de données des avis de restriction d'infrastructure et/ou celles relatives au sillon, dans la base de données du train.
Si le retard dépasse X minutes (cette valeur doit être définie dans le contrat entre l'EF et le GI), le GI concerné doit envoyer à l'EF un message de prévision de circulation du train concernant le prochain point d'observation.
Si le train est annulé, le GI envoie un message d'interruption de circulation du train, suivant les modalités précisées ci-après.
Dans les cas exceptionnels où l'EF ou le GI n'est pas en mesure de faire circuler le train à la date et à l'heure prévues, un nouveau sillon doit être négocié conformément au point 4.2.2 «Demande de sillon».
4.2.5.2. Message d'interruption de circulation du train
Si le train est annulé, ce message est envoyé par le GI au GI suivant et à l'EF qui a réservé le sillon.
Ce message doit contenir les principaux éléments d'information suivants:
— |
les numéros du sillon et du train, |
— |
l'identification du lieu, |
— |
la date et l'heure du départ prévues en ce lieu, |
— |
le motif de l'interruption, |
— |
la description de l'interruption. |
4.2.6. Localisation du train
4.2.6.1. Remarques préliminaires
Cette rubrique expose les possibilités de localisation des trains. L'EF peut envoyer à tout moment au GI une demande de renseignements concernant ses trains. Elle peut l'interroger sur:
— |
le parcours du train (dernier point de passage enregistré, retards, motifs du retard), |
— |
les performances du train (retards, motifs du retard, endroits des retards), |
— |
tous les identifiants du train, |
— |
les prévisions de circulation du train à un endroit donné, |
— |
toutes les prévisions de circulation du train à un endroit donné. |
L'accès à ces informations doit être indépendant des communications entre l'EF et le GI pendant le parcours du train, ce qui signifie que l'EF doit disposer d'une adresse d'accès unique ( (6)) à ces informations. Celles-ci sont principalement basées sur l'enregistrement des messages envoyés, comme on l'a vu précédemment.
4.2.6.2. Demande de renseignements sur les messages liés à la circulation du train
Objectif |
: |
permettre à l'EF d'obtenir des renseignements sur le dernier statut enregistré (emplacement, retards et motifs du retard) d'un train donné sur l'infrastructure d'un GI donné. |
||||||||||||||||||||
Demande de renseignements |
: |
principaux éléments d'information
|
||||||||||||||||||||
Réponse |
: |
informations fournies:
|
4.2.6.3. Demande de renseignements sur les messages relatifs aux retards et aux performances du train
Objectif |
: |
permettre à l'EF d'obtenir des informations sur tous les retards d'un train donné auprès d'un GI donné. |
||||||||||||||||||||||
Demande de renseignements |
: |
principaux éléments d'information
|
||||||||||||||||||||||
Réponse |
: |
il s'agit des mêmes informations que celles fournies pour la «demande de renseignements sur les messages liés à la circulation du train», non seulement pour ce qui concerne le dernier point, mais également pour chaque point d'observation du train sur l'infrastructure du GI donné:
|
4.2.6.4. Demande de renseignements sur les messages relatifs à l'identifiant du train
Objectif |
: |
permettre à l'EF de demander les renseignements sur l'identifiant du train en cours et les identifiants précédents. Il est possible d'utiliser n'importe quel identifiant pour un train donné. |
||||||||||||
Demande de renseignements |
: |
principaux éléments d'information
|
||||||||||||
Réponse |
: |
informations fournies:
|
4.2.6.5. Demande de renseignements au GI sur les messages relatifs aux prévisions de circulation du train
Objectif |
: |
permettre à l'EF de demander les renseignements sur l'heure prévue d'un train à un point d'observation donné ou, à défaut, au point de transfert du GI. |
||||||
Demande de renseignements |
: |
principaux éléments d'information
|
||||||
Réponse |
: |
informations fournies:
|
4.2.6.6. Demande de renseignements au GI sur les messages relatifs aux trains au lieu d'observation
Objectif |
: |
permettre à l'EF de demander les renseignements sur tous ses trains à un point d'observation donné sur l'infrastructure d'un GI donné. |
||||||||||||
Demande de renseignements |
: |
principaux éléments d'information
|
||||||||||||
Réponse |
: |
informations fournies:
|
4.2.7. HEP/HAP de la cargaison
4.2.7.1. Remarque préliminaire
Les points 4.2.2 «Demande de sillon» à 4.2.6 «Localisation du train» traitent essentiellement de la communication entre l'EF et le GI. Dans la mesure où la tâche du gestionnaire de l'infrastructure est de contrôler les trains, l'élément le plus important à mentionner dans les communications est le numéro du train. La partie du message sur la composition du train relative aux wagons est utilisée pour vérifier la composition du train sur la base des dispositions du contrat d'attribution du sillon conclu entre le GI et l'EF, ainsi que dans des cas exceptionnels.
Ces échanges d'informations ne couvrent pas le suivi des wagons ou des unités intermodales. Ce dernier est assuré par l'EF et l'EFP sur la base des messages relatifs aux trains et est décrit dans les points 4.2.7 «HEP/HAP de la cargaison» à 4.2.9 «Rapports d'échanges».
L'échange et la mise à jour des informations relatives aux wagons ou aux unités intermodales reposent essentiellement sur l'enregistrement des «plans d'acheminement» et des «mouvements des wagons» (point 4.2.12.2 «Autres bases de données»).
Comme l'indique le point 2.3.2 «Procédés envisagés», la donnée la plus importante pour un client est toujours l'heure d'arrivée prévue (HAP) de sa marchandise. Les HAP et HEP relatives aux wagons sont également à la base de la communication entre l'EFP et l'EF. Elles constituent le principal instrument permettant à l'EFP de surveiller le transport effectif de la marchandise et de contrôler le respect des engagements envers le client.
Les heures prévues communiquées dans les messages relatifs au train concernent toutes l'arrivée du train à un point donné, qu'il s'agisse d'un point de transfert, d'échange, de destination ou d'observation. Toutes ces heures sont des heures d'arrivée prévues du train (HAPT). Celles-ci peuvent être interprétées différemment selon le wagon ou l'unité intermodale. La HAPT à un point d'échange, par exemple, peut être une heure d'échange prévue (HEP) pour certains wagons ou unités intermodales. Pour d'autres wagons qui poursuivent le parcours sous la responsabilité de la même EF, elle pourrait n'avoir aucune pertinence. C'est à l'EF qu'il incombe, à la réception de la HAPT, de traiter cette information, autrement dit de l'insérer comme un mouvement de wagons dans la base de données opérationnelle des wagons et des unités intermodales et de la communiquer à l'EFP, si le train ne circule pas en accès libre. Cette procédure est abordée dans les chapitres suivants.
4.2.7.2. Calcul des HEP/HAP
Le calcul des HEP/HAP se base sur les informations fournies par le gestionnaire de l'infrastructure responsable, qui envoie, avec le message de prévision de circulation du train, l'heure d'arrivée prévue du train à des points d'observation définis (dans tous les cas aux points de transfert, d'échange ou d'arrivée, y compris les terminaux intermodaux) sur le sillon convenu. Il peut s'agir par exemple d'un point de transfert d'un GI donné au GI suivant (auquel cas la HAPT est identique à la HTP).
Pour les points d'échange ou pour les autres points d'observation définis sur le sillon convenu, l'EF doit calculer, pour l'EF suivante de la chaîne de transport, l'heure d'échange prévue (HEP) des wagons et/ou des unités intermodales.
Comme une EF peut disposer de wagons dont les parcours sont différents et dépendent d'EFP différentes au sein du même train, le point d'échange pour le calcul de la HEP peut varier d'un wagon à l'autre. Cette situation est expliquée dans les deux exemples simplifiés qui suivent (la représentation en images de ces scénarios figure à l'annexe A, index 5, chapitre 1.4 et le diagramme séquentiel basé sur l'exemple 1 pour le point d'échange C est présenté à l'annexe A, index 5, chapitre 5).
Exemple 1 |
: |
l'EF no 1 dispose des wagons no 1 et 2 de l'EFP no 1 et des wagons no 3 à 5 de l'EFP no 2 dans le même train. Au point d'échange C, la prise en charge des wagons 1 et 2 sera assurée par l'EF no 2 et celle des wagons 3 à 5 par l'EF no 3. Dans ce cas, l'EF no 1 doit calculer la HEP des wagons 1 et 2 au point d'échange C et doit envoyer ces valeurs à l'EFP no 1. Celle-ci doit à son tour calculer la HEP des wagons 3 à 5 au point d'échange C et envoyer ces valeurs à l'EFP no 2. |
Exemple 2 |
: |
l'EF no 1 dispose des wagons no 1 et 2 de l'EFP no 1 et des wagons no 3 à 5 de l'EFP no 2 dans le même train. Au point d'échange C, la prise en charge des wagons 3 à 5 sera assurée par l'EF no 3, tandis que les wagons 1 et 2 restent arrimés au train de l'EF no 1 jusqu'au point d'échange E, où ils sont transférés à l'EF no 2. Dans ce cas, l'EF no 1 doit uniquement calculer la HEP des wagons de 3 à 5 au point d'échange C et envoyer ces valeurs à l'EFP no 2. Le point d'échange C ne concerne pas les wagons 1 et 2. Le prochain point d'échange pour ces wagons est le E, pour lequel l'EF no 1 doit calculer la HEP et envoyer ces valeurs à l'EFP no 1. |
L'EF suivante calcule à son tour la HEP du wagon au point d'échange suivant, sur la base de la HEP indiquée par l'EF précédente. Cette procédure est appliquée par chaque EF. Lorsque la dernière EF (soit l'EF n) de la chaîne de transport d'un wagon reçoit de la part de l'EF qui la précède (soit l'EF n-1) la HEP de ce wagon au point d'échange entre les deux, l'EF n doit calculer l'heure d'arrivée prévue des wagons à la destination finale. Ceci permet de placer les wagons en fonction de la demande de wagons et selon les engagements de l'EFP vis-à-vis de son client. L'information indiquée est la HAP du wagon et doit être envoyée à l'EFP. Elle doit être enregistrée sur un support électronique, accompagnée des mouvements du wagon. L'EFP doit permettre à son client d'avoir accès aux données appropriées, selon les dispositions contractuelles.
Remarque: relative aux unités intermodales: pour les unités intermodales chargées sur un wagon donné, les HEP du wagon sont également les HEP des unités intermodales. Quant aux HAP de celles-ci, il faut noter que l'EF ne peut les calculer que dans le cadre du transport par voie ferrée. Par conséquent, elle peut uniquement fournir des HEP liées au terminal intermodal.
L'EFP est chargée de vérifier le respect des HEP sur la base des engagements envers le client.
Les écarts éventuels par rapport à ces engagements doivent être traités conformément au contrat et peuvent entraîner l'ouverture d'une procédure de gestion d'urgence par l'EFP. Le message d'alerte est prévu pour transmettre les résultats de cette procédure.
Sur la base de celle-ci, l'EFP doit pouvoir introduire des demandes d'informations sur les écarts éventuels liés à un wagon donné. Cette demande et la réponse correspondante de l'EF sont également décrites ci-après.
4.2.7.3. Message «HEP/HAP du wagon»
Objectif |
: |
permettre à l'EF d'envoyer la HEP (ou sa mise à jour) à l'EF qui lui succède dans la chaîne de transport des wagons. La dernière EF de la chaîne envoie la HAP (ou sa mise à jour) à l'EFP. |
||||||||||||||
Principaux éléments d'information: |
: |
|
4.2.7.4. Message d'alerte
Principaux éléments d'information: |
: |
|
Remarque: si l'exploitation s'effectue en accès libre, le calcul de la HEP et de la HAP est assuré entièrement par l'EF, qui fait alors office d'entreprise ferroviaire principale.
4.2.7.5. Demande de renseignements sur les messages liés aux écarts décelés
Objectif |
: |
permettre à l'EFP de demander des renseignements sur les écarts concernant un wagon donné. |
||||||||||||||||||
Demande de renseignements |
: |
principaux éléments d'information
|
||||||||||||||||||
Réponse |
: |
informations fournies:
|
4.2.8. Mouvements des wagons
4.2.8.1. Remarques préliminaires
Pour pouvoir rendre compte des mouvements des wagons, il est nécessaire d'enregistrer les données suivantes et de les rendre accessibles par voie électronique. Elles doivent également être échangées dans les messages envoyés aux parties autorisées, conformément aux dispositions contractuelles. Les formats détaillés sont définis à l'annexe A, index 1.
— |
L'avis de libération du wagon |
— |
L'avis de départ du wagon |
— |
L'arrivée du wagon au dépôt |
— |
Le départ du wagon du dépôt |
— |
Le message de notification d'incident |
— |
L'avis d'arrivée du wagon |
— |
L'avis de livraison du wagon |
— |
La confirmation de la livraison du wagon |
— |
Le compte rendu des échanges des wagons fera l'objet d'une description séparée au point 4.2.9 «Rapports d'échanges». |
4.2.8.2. Avis de libération du wagon
Objectif |
: |
cet avis est envoyé à l'EF par l'EFP. Si celle-ci n'est pas la première EF de la chaîne de transport, elle doit informer l'EF responsable que le wagon est prêt à partir (le lieu de départ dépend des engagements pris par l'EFP), au moment de libération indiqué (date et heure du départ). Cette communication doit être enregistrée dans la base de données opérationnelle des wagons et des unités intermodales. |
||||||||||||
Principaux éléments d'information |
: |
Les données suivantes doivent être facilement accessibles à l'EF et à l'EFP dans la base de données:
|
4.2.8.3. Avis de départ du wagon
Objectif |
: |
l'EF envoie cet avis à l'EFP afin de l'informer de l'heure et de la date réelles du départ du wagon. Cette communication doit être enregistrée dans la base de données opérationnelle des wagons et des unités intermodales. L'envoi de ce message permet le transfert de la responsabilité du wagon entre le client et l'EF. |
||||||||||||
Principaux éléments d'information |
: |
Les données suivantes doivent être facilement accessibles à l'EF et à l'EFP dans la base de données:
|
4.2.8.4. Avis d'arrivée du wagon au dépôt
Objectif |
: |
l'EF doit informer l'EFP que le wagon est arrivé à son dépôt. Ce message peut être fondé sur le message de notification sur la circulation du train décrit au point 4.2.4 «(Prévision de circulation du train»). Cette communication doit être enregistrée dans la base de données opérationnelle des wagons et des unités intermodales. |
||||||
Principaux éléments d'information |
: |
|
4.2.8.5. Avis de départ du wagon du dépôt
Objectif |
: |
l'EF doit informer l'EFP que le wagon a quitté son dépôt. Ce message peut être fondé sur le message de notification sur la circulation du train décrit au point 4.2.4 «Prévision de circulation du train»). Cette communication doit être enregistrée dans la base de données opérationnelle des wagons et des unités intermodales. |
||||||
Principaux éléments d'information |
: |
|
4.2.8.6. Message de notification d'incident
Objectif |
: |
l'EF doit informer l'EFP de tout incident éventuel en rapport avec le wagon, et qui pourrait avoir un impact sur la HEP et la HAP ou qui nécessite des mesures supplémentaires. Dans la plupart des cas, ce message doit être accompagné d'une nouvelle HEP/HAP. Si l'EFP a besoin d'une nouvelle HEP/HAP, elle envoie un message à l'EF concernée avec la mention «HEP/HAP demandée» (Message de notification d'incident: demande d'une nouvelle HEP/HAP). Le calcul de la nouvelle HEP/HAP doit suivre la procédure décrite au point 4.2.7 «HEP/HAP de la cargaison»). Ces informations doivent être enregistrées dans la base de données opérationnelle des wagons et des unités intermodales. |
||||||||||
Principaux éléments d'information |
: |
En outre, les données suivantes doivent être facilement accessibles et enregistrées dans les bases de données:
|
4.2.8.7. Message de notification d'incident: demande d'une nouvelle HEP/HAP
Objectif |
: |
l'EFP peut envoyer ce message à l'EF à l'origine du message de notification d'incident, pour demander le calcul d'une nouvelle HEP/HAP. Elle envoie également ce message à toutes les EF qui lui succèdent pour les informer du retard. Elle décide s'il est nécessaire de calculer une nouvelle HEP/HAP, car celle-ci est inutile dans certains cas. |
||||||||||||
Principaux éléments d'information |
: |
En outre, les données suivantes doivent être facilement accessibles et enregistrées dans la base de données:
|
4.2.8.8. Avis d'arrivée du wagon
Objectif |
: |
la dernière EF de la chaîne de transport d'un wagon ou d'une unité intermodale doit informer l'EFP de l'arrivée du wagon à son dépôt (site de l'EF). |
||||||
Principaux éléments d'information |
: |
|
4.2.8.9. Avis de livraison du wagon
Objectif |
: |
la dernière EF de la chaîne de transport doit informer l'EFP que le wagon a été placé sur le faisceau de voies du destinataire. |
||||||
Principaux éléments d'information |
: |
|
L'avis de livraison du wagon peut être envoyé une seconde fois comme «confirmation de la livraison du wagon», avec la donnée supplémentaire suivante:
— |
l'identification du client. |
Remarque: si l'exploitation a lieu en accès libre, le mouvement du wagon décrit est assuré entièrement par l'EF (EFP), à qui il incombe d'effectuer tous les calculs ainsi que l'enregistrement des données, étant donné qu'elle fait office d'EFP liée au client par un contrat et un engagement.
Le diagramme séquentiel de ces messages, basé sur l'exemple 1 relatif au calcul de la HEP des wagons 1 et 2 (voir le point 4.2.7.2 «Calcul des HEP/HAP»), est intégré au diagramme relatif aux rapports d'échange, à l'annexe A, index 5, chapitre 6.
4.2.9. Rapports d'échanges
4.2.9.1. Remarque préliminaire
Les rapports d'échanges portent sur les messages relatifs au transfert de responsabilité du wagon entre deux entreprises ferroviaires aux points d'échange. Il contraint en outre la nouvelle EF à calculer une HEP et à suivre la procédure décrite au point 4.2.7 «HEP/HAP de la cargaison».
Les messages suivants doivent être envoyés:
— |
l'avis d'échange du wagon, |
— |
l'avis d'échange du wagon (message secondaire), |
— |
le wagon reçu au point d'échange, |
— |
le wagon refusé au point d'échange. |
Les données contenues dans ces messages doivent être enregistrées dans la base de données opérationnelle des wagons et des unités intermodales. En cas de retard, une nouvelle HEP/HAP doit être calculée et transmise conformément à la procédure décrite au point 4.2.7 «HEP/HAP de la cargaison». Le diagramme séquentiel de ces messages est présenté avec les messages de mouvements des wagons à l'annexe A, index 5, chapitre 6.
Les avis d'échange du wagon (message principal et secondaire) ainsi que les messages «wagon reçu» peuvent inclure plusieurs wagons, notamment si ceux-ci sont arrimés au même train. Dans ce cas, tous les wagons peuvent être mentionnés dans un seul message.
Si l'exploitation a lieu en accès libre, il n'y a pas de point d'échange. La responsabilité des wagons ne change pas aux points de manœuvre. Par conséquent, aucun message particulier n'est nécessaire. Toutefois, à partir de la notification sur la circulation du train à un point d'observation donné, les informations relatives aux wagons ou aux unités intermodales — le lieu, la date et l'heure d'arrivée et de départ — doivent être traitées et enregistrées dans la base de données opérationnelle des wagons et des unités intermodales.
Ces messages sont décrits ci-après.
4.2.9.2. L'avis d'échange du wagon
Objectif |
: |
avec cet avis, l'EF no 1 demande à l'EF no 2 de la chaîne de transport si elle accepte de prendre le wagon en charge. Au moyen du message secondaire de l'avis d'échange du wagon, l'EF no 2 informe le GI qu'elle a accepté de le prendre en charge jusqu'à l'EF suivante. |
||||||||||||||
Principaux éléments d'information |
: |
En outre, les données suivantes doivent être facilement accessibles et enregistrées dans les bases de données:
|
4.2.9.3. Avis d'échange du wagon (message secondaire)
Objectif |
: |
le message secondaire d'avis d'échange du wagon permet à l'EF no 2 d'informer le GI qu'elle prend en charge le wagon. |
||||||||
Principaux éléments d'information |
: |
En outre, l'élément suivant doit être facilement accessible et enregistré dans les bases de données:
|
4.2.9.4. Wagon reçu au point d'échange
Objectif |
: |
le message «wagon reçu au point d'échange» permet à l'EF no 2 d'informer l'EF no 1 qu'elle accepte de prendre en charge le wagon. |
||||
Principaux éléments d'information |
: |
|
4.2.9.5. Wagon refusé au point d'échange
Objectif |
: |
le message «wagon refusé au point d'échange» permet à l'EF no 2 d'informer l'EF no 1 qu'elle ne souhaite pas prendre en charge le wagon. |
||||||||
Principaux éléments d'information |
: |
|
4.2.10. Échange de données pour l'amélioration de la qualité
Pour être compétitif, le secteur européen du rail doit fournir à ses clients des services de grande qualité (voir également l'annexe III, article 2.7.1, de la directive 2001/16/CE).
Il importe de procéder à une évaluation une fois l'acheminent du fret terminé, de manière à améliorer la qualité des services.
En plus de cette évaluation, les EFP, les EF et les GI doivent évaluer la qualité des éléments du service, qui font partie intégrante du produit fourni.
Cette procédure requiert des GI et des EF (notamment s'il s'agit d'EFP) qu'ils choisissent un paramètre de qualité donné, un itinéraire ou un lieu et une période d'évaluation afin de mesurer les performances sur la base des critères prédéterminés, qui sont normalement définis dans un contrat.
Les résultats de cette évaluation doivent démontrer clairement le degré de conformité des services fournis par rapport à l'objectif convenu entre les parties au contrat.
La précision des rapports d'évaluation doit être telle qu'elle permet d'identifier l'endroit qui pose problème et les raisons possibles de la baisse de qualité, par exemple des retards. L'analyse des causes premières de cette baisse doit ensuite porter sur les défaillances récurrentes, de manière à permettre aux parties au contrat de prendre les mesures adéquates.
Le GI et l'EF sont tenus de fournir des informations, de participer à l'analyse des causes premières de ces défaillances, éventuellement avec des tiers, et de mettre en œuvre toutes les mesures rectificatives convenues.
L'évaluation doit être répétée à plusieurs reprises.
Pour estimer la qualité des services, les messages présentés ci-avant peuvent être utilisés conformément aux 6 rubriques ci-dessous.
1. EFP/Client: temps de transit, HAP, résolution d'alerte
Les contrats entre les EF qui agissent comme intégrateurs de services (EFP) et leurs clients peuvent contenir des dispositions particulières (en fonction de l'accord concerné) quant au temps de transit, à la HAP et à la résolution d'alerte. Les messages les plus appropriés pour cette évaluation de la qualité sont:
l'avis de libération,
l'avis de départ,
l'avis de livraison.
2. EFP/Prestataires de services: temps de transit et de manœuvre, HAP, HEP, codes de motif
Les contrats entre les EFP et d'autres prestataires de services de transport peuvent contenir des dispositions concernant le temps de transit (en heures) sur la base des éléments suivants:
le temps entre la libération et la livraison au point d'échange,
le temps entre l'enlèvement et le point de contrôle,
le temps entre le point de contrôle et le chargement,
le temps entre la réception et la livraison au point d'échange,
le temps entre la réception au point d'échange et la mise à disposition/mise en attente,
le temps entre le déchargement et la livraison.
Les messages les plus appropriés pour cette évaluation de la qualité sont:
l'avis de libération,
l'avis de départ,
l'arrivée au dépôt,
le départ du dépôt,
l'avis d'arrivée,
l'avis d'échange du wagon,
le wagon reçu au point d'échange,
le wagon refusé au point d'échange.
3. EF/GI: ponctualité du train, HAP du train (HAPT), HTP
Les contrats entre les EF et les GI peuvent prévoir un niveau de ponctualité des trains à des points d'observation donnés ainsi qu'un niveau d'exactitude des HAP et HTP des convois. Les messages les plus appropriés pour cette évaluation de la qualité sont:
la prévision de circulation du train,
la notification sur la circulation du train,
la demande de renseignements/la réponse relative au retard/à la ponctualité des trains.
4. EF/GI: disponibilité (prévue) du sillon
Les contrats entre les EF et les GI doivent préciser clairement la disponibilité de sillons pour la circulation des trains au moyen de plages de temps à des endroits donnés, de même que les spécifications des trains en termes de longueur maximale, de poids brut, de volume et de chargement, etc. Cet aspect sera abordé dans la rubrique no 6, ci-dessous (GI/EF: Qualité de la composition du train).
Les procédures et les délais de confirmation de l'utilisation des sillons, d'annulation de l'utilisation prévue, ainsi que la possibilité d'utiliser un sillon en dehors des plages de temps spécifiées (avant ou après) doivent également être définies dans les contrats. Les messages les plus appropriés pour cette évaluation de la qualité sont:
sillon annulé,
sillon non disponible.
5. EF/GI: demande de sillon à court terme
Lorsque l'EF désire exploiter un train en dehors des échéances prévues dans le cadre du sillon concerné, elle doit envoyer une demande de sillon à court terme au(x) GI concerné(s) (conformément à la directive 2001/14/CE).
L'EF comparera périodiquement la demande de sillon et les réponses correspondantes afin d'établir les relevés suivants:
comparaison entre le temps de réponse à la demande et celui prévu par l'accord-cadre,
comparaison entre le nombre de sillons octroyés dans un délai donné et ceux octroyés dans le délai demandé,
prise en considération du nombre de demandes de sillon refusées.
Les messages les plus appropriés pour cette évaluation de la qualité sont:
demande de sillon,
détails du sillon,
détails du sillon refusés,
sillon annulé,
sillon non disponible.
6. GI/EF: qualité de la composition du train
Les messages «train prêt» et/ou les listes de composition du train envoyés par l'EF au(x) GI(s) (ou à d'autres EF) doivent observer les spécifications contenues dans le contrat concerné. Pour contrôler le respect de cette exigence et évaluer ainsi la qualité de la composition du train, les messages les plus pertinents sont les suivants:
composition du train,
train non approprié.
4.2.11. Données de référence principales
4.2.11.1. Remarques préliminaires
Les données d'infrastructure (les documents de référence du réseau et les données enregistrées dans la base de données des avis de restriction d'infrastructure) et celles relatives au matériel roulant (dans les bases de données de référence du matériel roulant et dans la base de données opérationnelle des wagons et des unités intermodales) sont les plus importantes pour l'exploitation de trains de marchandises sur le réseau européen. Elles permettent de procéder à une évaluation de la compatibilité du matériel roulant avec l'infrastructure et contribuent à simplifier la collecte des données, ce qui augmente en particulier la qualité de celles-ci. Elles donnent par ailleurs une image précise de l'ensemble des installations et des équipements disponibles à tout moment, ce qui permet de prendre des décisions rapidement pendant le parcours du train.
4.2.11.2. Bases de données d'avis de restriction d'infrastructure
Chaque GI est responsable du caractère approprié du sillon sur son infrastructure, tandis que l'EF est tenue de contrôler les caractéristiques du train sur la base des valeurs indiquées dans les détails du sillon concerné.
Sans préjudice des conditions d'utilisation d'un sillon présentées dans les documents de référence du réseau ou des responsabilités en cas de restrictions d'infrastructure mentionnées dans la STI «Exploitation et gestion du trafic», l'EF doit avoir connaissance, avant la préparation du train, de l'existence de restrictions sur des segments de ligne ou dans des gares (nœuds) susceptibles d'affecter la composition du train définie dans le contrat d'attribution du sillon.
À cette fin, les GI doivent créer et compléter des bases de données d'avis de restriction d'infrastructure. La structure de ces bases de données est définie à l'annexe A, index 2. Leurs entrées sont basées sur les segments correspondant aux différents documents de référence du réseau et sur les restrictions éventuelles. Ces bases de données doivent être accessibles via l'interface commune (points 4.2.14.1 «Architecture générale» et 4.2.14.7 «Interface commune»).
L'EF est tenue de tenir compte de toutes les restrictions contenues dans la base de données des avis de restriction d'infrastructure et susceptibles affecter la circulation de son train jusqu'au prédépart. Sauf dispositions contraires prévues dans le contrat entre le GI et l'EF, la période de prédépart commence une heure avant l'heure de départ prévue.
Durant cette période, le GI doit informer directement l'EF de tout changement qui la concerne dans la base de données des avis de restriction d'infrastructure.
4.2.11.3. Bases de données de référence du matériel roulant
Le détenteur du matériel roulant est responsable du stockage des données relatives à ce matériel roulant dans une base de données de référence.
Les informations que celle-ci doit contenir sont détaillées à l'annexe A, index 2. Il s'agit des éléments suivants:
— |
l'identification du matériel roulant; |
— |
l'évaluation de la compatibilité avec les infrastructures, |
— |
l'évaluation des caractéristiques de chargement pertinentes, |
— |
les caractéristiques de freinage nécessaires, |
— |
les données de maintenance, |
— |
les caractéristiques environnementales. |
Les bases de données de référence du matériel roulant doivent permettre d'accéder facilement (un accès commun fourni via l'interface commune) aux données techniques et réduire ainsi le volume des données transmises pour chaque opération. Sur la base des droits d'accès structurés en fonction des privilèges octroyés, le contenu des bases de données doit être accessible à l'ensemble des prestataires de services (GI, EF, prestataires de services logistiques et gestionnaires de flotte), en particulier à des fins de gestion de la flotte et de maintenance du matériel roulant.
Les entrées de la base de données de référence du matériel roulant peuvent être groupées comme suit:
— |
les données administratives, relatives à la certification et à l'enregistrement, notamment le fichier d'immatriculation CE, l'identité de l'organisme notifié, etc. Il peut en outre s'agir de données antérieures sur la propriété, les locations, etc. Les éléments suivants doivent être pris en considération:
Le détenteur est tenu de veiller à la disponibilité de ces documents et des procédures qui y sont liées. |
— |
les données de conception, qui doivent comprendre tous les éléments constitutifs (physiques) du matériel roulant, y compris les caractéristiques environnementales ainsi que toutes les informations supposées valables durant toute la durée de vie du matériel roulant — cette partie peut contenir un historique des modifications importantes, de la maintenance, de la révision, etc. |
4.2.11.4. Données opérationnelles du matériel roulant
En plus des données de référence sur le matériel roulant, celles qui indiquent le «statut» réel du matériel roulant sont les plus importantes aux fins de l'exploitation.
Ces informations doivent comprendre des éléments à caractère temporaire, tels que les restrictions, les mesures de maintenance actuelles et programmées, le kilométrage, les avaries, etc. Elles doivent en outre mentionner tout ce qui concerne le «statut» (limites de vitesse provisoires, freins isolés, réparations nécessaires et descriptions des avaries, etc.).
Pour l'utilisation des données opérationnelles du matériel roulant, il faut distinguer trois rubriques, étant donné que trois acteurs différents sont responsables de ce matériel au cours du transport:
— |
l'entreprise ferroviaire en tant que responsable du contrôle du transport, |
— |
le détenteur du matériel roulant, et |
— |
l'utilisateur (locataire) du matériel roulant. |
Ces données doivent être accessibles aux utilisateurs autorisés, selon ses droits d'accès prédéterminés, au moyen de l'identifiant du wagon, c'est-à-dire de son numéro.
Les données opérationnelles du matériel roulant font partie de la base de données opérationnelle des wagons et des unités intermodales décrite au point 4.2.12.2 «Autres bases de données».
4.2.12. Fichiers de référence et bases de données
4.2.12.1. Fichiers de référence
Pour l'exploitation des trains de marchandises sur le réseau européen, les fichiers de référence suivants doivent être mis à la disposition de tous les prestataires de services (GI, EF, prestataires de services logistiques et gestionnaires de flotte). Les informations doivent refléter à tout moment l'état réel du matériel.
Stockage et gestion locale:
— |
le fichier de référence des services d'urgence, en corrélation avec le type de marchandise dangereuse |
Stockage et gestion centralisés:
— |
le fichier de référence du codage de tous les GI, EF et prestataires de services, |
— |
le fichier de référence du codage des clients, |
— |
le fichier de référence du codage des sites (primaires, secondaires et zone-voie-emplacement), |
— |
le fichier de référence du codage des sites des clients, |
— |
le fichier de référence de tous les systèmes de contrôle des trains de marchandises dangereuses, numéros ONU et RID, |
— |
le fichier de référence des marchandises dangereuses, des numéros ONU et RID, |
— |
le fichier de référence de tous les types de locomotive, |
— |
le fichier de référence de tous les codes NC et SH des marchandises, |
— |
le fichier de référence de tous les ateliers de maintenance européens, |
— |
le fichier de référence de tous les organismes de contrôle européens, |
— |
le fichier de référence de tous les opérateurs européens accrédités et la liste des certificats de sécurité octroyés au niveau national. |
Le codage des GI, des EF, des organismes et des sociétés de transport, des clients et des sites (primaires, secondaires, etc.), dont les sites des clients, est en suspens.
4.2.12.2. Autres bases de données
Pour permettre le suivi des trains et des wagons, il est nécessaire de créer les bases de données suivantes et de les mettre à jour à chaque fois que cela s'avère nécessaire. Les acteurs. autorisés tels que les détenteurs et les gestionnaires de flotte doivent avoir accès aux données appropriées dans l'exercice de leurs fonctions, selon des conditions prévues par le contrat.
— |
Base de données opérationnelle des wagons et des unités intermodales |
— |
Plan d'acheminement pour les wagons/unités intermodales |
Ces bases de données doivent être accessibles via l'interface commune (points 4.2.14.1 «Architecture générale» et 4.2.14.7 «Interface commune»).
Base de données opérationnelle des wagons et des unités intermodales
La communication entre l'EFP et les EF en mode de coopération repose sur les numéros des wagons et/ou des unités intermodales. Par conséquent, l'EF qui communique avec les GI à propos d'un convoi doit ventiler ces informations entre les wagons et les unités intermodales et les enregistrer dans la base de données opérationnelle des wagons et des unités intermodales. Les informations relatives aux mouvements des trains doivent y être consignées sous la forme de nouvelles entrées ou de mises à jour. La rubrique relative aux mouvements des wagons ou des unités intermodales est créée dans la base de données au plus tard lorsque le client communique l'heure de libération de ces wagons ou de ces unités. Cette heure est la première entrée de cette base de donnée relative au parcours du convoi. Les messages relatifs aux mouvements des wagons sont définis aux points 4.2.8 «Mouvements des wagons» et 4.2.9 «Rapports d'échanges». Cette base de données doit être accessible via l'interface commune (points 4.2.14.1 «Architecture générale» et 4.2.14.7 «Interface commune»).
La base de données opérationnelle des wagons et des unités intermodales est la plus importante pour le suivi des wagons et, par conséquent, pour les communications entre les EF concernées et l'EFP. Elle décrit les mouvements du wagon et de l'unité intermodale depuis le départ jusqu'à livraison finale sur les voies de service du client et mentionne les HEP et les heures réelles d'arrivée aux différents sites jusqu'à la HAP de la livraison finale. Elle présente également les différents statuts du matériel roulant tels que:
— |
le chargement du matériel roulant. |
Ce statut est requis pour les échanges d'informations entre l'EF et les GI ainsi que pour les autres entreprises ferroviaires impliquées dans le transport.
— |
Wagon chargé en cours de route |
Ce statut est requis pour les échanges d'informations entre le GI et l'EF ainsi que pour les autres gestionnaires d'infrastructure et les autres entreprises ferroviaires impliquées dans le transport.
— |
Wagon vide sur le parcours |
Ce statut est requis pour les échanges d'informations entre le GI et l'EF ainsi que pour les autres gestionnaires d'infrastructure et les autres entreprises ferroviaires impliquées dans le transport.
— |
Identification du matériel roulant |
Ce statut est requis pour les échanges d'informations entre l'EF de destination et l'EFP pour le transport.
— |
Wagon vide sous le contrôle de la gestion de la flotte |
Ce statut est nécessaire à l'obtention d'informations sur la disponibilité d'un type précis de véhicule.
Bases de données sur le plan d'acheminement des wagons
Les trains transportent normalement les wagons de plusieurs clients. Pour chaque wagon, l'EFP (EF agissant en tant qu'intégrateur de services) doit élaborer et mettre à jour un plan d'acheminement qui correspond au sillon du train. L'attribution de nouveaux sillons — par exemple en cas d'interruption du service — nécessite la révision des plans d'acheminement des wagons concernés. La date et l'heure de création de ces plans est celle de la réception de la lettre de voiture du client.
Les plans d'acheminement des wagons doivent être enregistrés par chaque EFP dans une base de données, qui doit être accessible via l'interface commune (points 4.2.14.1 «Architecture générale» et 4.2.14.7 «Interface commune»).
Remarque:
En plus des bases de données obligatoires mentionnées ci-dessus, chaque GI peut créer une base de données des trains.
Cette base de donnée correspond à la base de données opérationnelle des wagons et des unités intermodales. Elle contient principalement les données qui correspondent au message de composition des trains transmis par l'EF. Toutes les modifications relatives au train nécessitent la mise à jour de cette base de données. Il est également possible d'enregistrer ces informations dans la base de données relative au sillon (point 4.2.2 «Demande de sillon»). Ces bases de données doivent être accessibles via l'interface commune (points 4.2.14.1 «Architecture générale» et 4.2.14.7 «Interface commune»).
4.2.12.3. Dispositions supplémentaires relatives aux bases de données
On trouvera ci-dessous les critères supplémentaires auxquels doivent répondre les bases de données.
1. |
Authentification La base de données doit garantir l'authentification des utilisateurs des systèmes avant qu'ils ne puissent y accéder. |
2. |
Sécurité La base de données doit prévoir les aspects de sécurité en garantissant le contrôle de son accès. Le cryptage éventuel de son contenu n'est pas une obligation. |
3. |
Cohérence La base de données doit garantir le principe ACID (atomicité, cohérence, isolement, durabilité). |
4. |
Contrôle d'accès La base de données doit être accessible aux utilisateurs ou aux systèmes qui bénéficient d'une autorisation. Le contrôle d'accès doit être appliqué jusqu'au plus petit élément. Il doit pouvoir être configuré en fonction des utilisateurs pour l'insertion, la mise à jour ou la suppression des données. |
5. |
Localisation La base de données doit garantir le suivi de toutes les modifications qui y sont apportées pour permettre la traçabilité des saisies (auteur, objet et moment de la modification). |
6. |
Stratégie de verrouillage La base de données doit permettre la mise en œuvre d'une stratégie de verrouillage qui permet d'accéder à son contenu même lorsque d'autres utilisateurs sont en train de modifier des enregistrements. |
7. |
Accès multiples La base de données doit garantir l'accès simultané de plusieurs utilisateurs ou systèmes à son contenu. |
8. |
Fiabilité La fiabilité de la base de données doit garantir la disponibilité requise. |
9. |
Disponibilité La disponibilité de la base de données doit satisfaire à la demande dans au moins 99,9 % des cas. |
10. |
Maintenance La maintenance de la base de données doit garantir la disponibilité requise. |
11. |
Sécurité Les bases de données n'ont pas un contenu «sensible» au niveau de la sécurité. Par conséquent, les aspects de sécurité ne sont pas concernés en l'occurrence. Cela ne signifie pas que les données proprement dites — par exemple si elles sont erronées ou désuètes — ne peuvent pas avoir de répercussions sur la sécurité de l'exploitation du train. |
12. |
Compatibilité La base de données doit se baser sur un langage de manipulation couramment accepté, tel que le SQL ou le XQL. |
13. |
Utilitaire d'importation La base de données doit disposer d'un utilitaire qui permet d'y importer des données formatées au lieu de les insérer manuellement. |
14. |
Utilitaire d'exportation La base de données doit disposer d'un utilitaire qui permet d'exporter tout ou partie de son contenu sous une forme formatée. |
15. |
Champs obligatoires La base de données doit comporter des champs obligatoires à remplir avant l'acceptation de nouvelles données. |
16. |
Contrôles de vraisemblance La base de données doit faire l'objet de contrôles de vraisemblance configurables avant l'acceptation de l'insertion, de la mise à jour ou de la suppression de données. |
17. |
Temps de réponse La base de données doit permettre un temps de réponse suffisant afin que l'utilisateur puisse insérer, mettre à jour ou supprimer des enregistrements. |
18. |
Performances La base de données doit permettre un nombre de consultations suffisant afin de garantir son efficacité face aux quelque 60 000 mouvements de train enregistrés toutes les 24 heures. Environ 50 % de ces mouvements se succèdent dans un intervalle de deux heures. Le nombre et le type de consultations ou de mises à jour par train dépendent de la procédure globale de planification et d'exploitation. |
19. |
Capacités La base de données doit permettre l'enregistrement des données pertinentes de tous les wagons de marchandises sur l'ensemble du réseau. Elle doit prévoir la possibilité d'accroître facilement ses capacités (par exemple par l'ajout de plus grandes capacités d'enregistrements et de davantage d'ordinateurs). Les extensions de capacités ne doivent pas nécessiter le remplacement du sous-système. |
20. |
Données historiques La base de données doit prévoir la gestion des données historiques, c'est-à-dire la possibilité de consulter des données qui ont déjà été archivées. |
21. |
Stratégie de sauvegarde La stratégie de sauvegarde doit garantir la récupération de toutes les données datant de 24 heures maximum. |
22. |
Aspects commerciaux Le système utilisé doit être un produit commercial ou un publiciel. |
Remarques
Les critères susmentionnés doivent être traités par un système de gestion de bases de données standard (SGBD).
L'utilisation des bases de données repose sur les diverses opérations décrites ci-dessus. Leur fonctionnement général repose sur un mécanisme de questions/réponses dans lequel l'utilisateur demande des informations à la base de données via l'interface commune (points 4.2.14.1 «Architecture générale» et 4.2.14.7 «Interface commune»). Le SGBD répond à cette demande: soit il fournit les données demandées, soit il répond qu'aucune donnée n'est disponible (elles n'existent pas ou l'accès à celles-ci est refusé).
4.2.13. Transmission électronique de documents
Le point 4.2.14 «Mise en réseau et communication» décrit le réseau de communication à utiliser pour l'échange de données. Ce réseau et les mesures de sécurité qui y sont liées permettent n'importe quel type de communication: courrier électronique, transfert de fichiers (FTP, HTTP), etc. Les utilisateurs peuvent donc décider eux-mêmes du type de communication qu'ils vont choisir, par exemple le protocole FTP.
4.2.14. Mise en réseau et communication
4.2.14.1. Architecture générale
Au fil du temps, ce sous-système verra l'émergence d'une collectivité ferroviaire vaste et complexe impliquant une interopérabilité télématique et des interactions entre des centaines d'intervenants (EF, GI…) qui se feront concurrence et/ou qui coopéreront pour répondre aux besoins du marché.
L'infrastructure de mise en réseau et de communication qui sous-tendra cette communauté d'interopérabilité sera fondée sur une architecture d'échange d'informations connue et adoptée par tous les intervenants.
Cette architecture:
— |
est conçue pour harmoniser des modèles d'informations hétérogènes en effectuant la transformation sémantique des données échangées entre les systèmes et en conciliant les divergences entre les processus commerciaux et les protocoles au niveau des applications, |
— |
aura des répercussions minimes sur les architectures informatiques existantes utilisées par les intervenants, |
— |
préservera les investissements déjà consentis en matière de technologie de l'information. |
L'architecture d'échange d'informations repose essentiellement sur des interactions de type «poste à poste» entre les intervenants, tout en garantissant l'intégrité et la cohérence générales de la communauté ferroviaire d'interopérabilité en fournissant un ensemble de services centralisés.
Le modèle d'interaction «poste à poste» permet une répartition optimale des coûts entre les différents intervenants, sur la base de l'utilisation réelle qui en est faite. Il sera en général moins vulnérable aux problèmes de modularité. La représentation en image de l'architecture générale est donnée à l'annexe A, index 5, chapitre 1.5.
4.2.14.2. Réseau
La mise en réseau désigne ici la méthode et la philosophie de communication et non le réseau proprement dit.
L'interopérabilité dans le domaine ferroviaire est basée sur une architecture d'échange d'informations connue et adoptée par tous les participants, ce qui encouragera d'autres acteurs à y adhérer, en particulier les clients.
L'aspect de la sécurité ne sera pas pris en charge au niveau du réseau (RPV, tunnellisation…). Les messages échangés seront préalablement sécurisés. Il n'est donc pas nécessaire d'utiliser un RPV (réseau privé virtuel) (la gestion de ce type de réseau à une si grande échelle serait complexe et coûteuse), ce qui permet d'éviter les problèmes de responsabilité et d'appropriation. La tunnellisation n'est pas jugée nécessaire pour atteindre le niveau de sécurité approprié.
Néanmoins, les intervenants qui disposent déjà de plusieurs niveaux de sécurité sur des sections réservées du réseau ou qui souhaitent en créer sont autorisés à le faire.
Il est possible d'utiliser l'internet pour mettre en œuvre un modèle «poste à poste» hybride, avec un répertoire central et une interface commune à chaque nœud entre les intervenants.
Le répertoire central est le premier point de contact pour obtenir des méta-informations, telles que l'identité du poste (intervenant) sur lequel certaines informations sont enregistrées, ou pour vérifier les certificats de sécurité. Ensuite, la communication de «poste à poste» est engagée entre les intervenants concernés.
4.2.14.3. Protocoles
Seuls les protocoles qui font partie de l'Internet Protocol Suite peuvent être utilisés.
4.2.14.4. Sécurité
Pour garantir un niveau de sécurité élevé, les informations contenues dans les messages doivent être sécurisées et le destinataire doit être en mesure d'en vérifier l'authenticité. Cette garantie est mise en œuvre par l'utilisation d'un système de cryptage et de signatures similaire à celui utilisé pour le courrier électronique. Il permet d'utiliser n'importe quel type de transmission: courrier électronique, transfert de fichiers (ftp, http), etc. Le choix de ce type de transmission appartient aux parties concernées.
4.2.14.5. Cryptage
Il faut utiliser soit un cryptage asymétrique, soit une solution hybride fondée sur un cryptage symétrique pourvu d'un système de protection à clé publique, car le partage d'une clé secrète commune entre de nombreux intervenants entraînera des problèmes à un moment donné. Il est plus facile de garantir un niveau de sécurité élevé si chaque intervenant est responsable de sa propre paire de clés, même si cela requiert un niveau d'intégrité élevé du répertoire central (serveur de clés).
4.2.14.6. Répertoire central
Le répertoire central devra prendre en charge:
— |
les métadonnées (des données structurées qui décrivent le contenu des messages), |
— |
l'infrastructure à clé publique (ICP), |
— |
l'organisme de certification (OC), |
— |
le répertoire («annuaire»), qui contient les informations nécessaires relatives aux participants aux échanges de messages. |
La responsabilité de la gestion du répertoire central devra incomber à un organisme européen non commercial.
4.2.14.7. Interface commune
L'interface commune est obligatoire pour tous les participants désireux d'adhérer à la communauté d'interopérabilité.
L'interface commune devra prendre en charge:
— |
le formatage des messages sortants, conformément aux métadonnées, |
— |
la signature et le cryptage des messages sortants, |
— |
l'adressage des messages sortants, |
— |
la vérification de l'authenticité des messages entrants, |
— |
le décryptage des messages entrants, |
— |
les contrôles de conformité des messages entrants par rapport aux métadonnées, |
— |
l'accès commun unique aux diverses bases de données. |
Tous les utilisateurs de l'interface commune auront accès à toutes les données requises en fonction des STI relatives aux différents GI, EF, etc., indépendamment du fait que la base de données concernée est centrale ou individuelle (voir également l'annexe A, index 5, chapitre 1.6).
La vérification de l'authenticité des messages entrants prévoit deux possibilités de reconnaissance du message:
i) |
accusé de réception positif; |
ii) |
accusé de réception négatif. |
L'interface commune gérera les tâches susmentionnées en utilisant les informations du répertoire central.
Le participant peut faire usage d'un «miroir» local du répertoire central pour raccourcir les délais de réponse.
4.3. Spécifications fonctionnelles et techniques des interfaces
Les spécifications fonctionnelles et techniques des interfaces en fonction des exigences essentielles décrites au chapitre 3 sont présentées ci-dessous.
4.3.1. Interfaces avec la STI relative à l'infrastructure
Le sous-système «Infrastructure» inclut la gestion du trafic, le suivi et les systèmes de navigation: installations techniques utilisées dans le traitement des données et les télécommunications dans les transports de passagers et de fret sur longue distance afin de garantir la sécurité et la fluidité de l'exploitation du réseau ferroviaire, ainsi que l'efficacité de la gestion du trafic.
Le sous-système «Applications télématiques au service de fret» utilise les données nécessaires à l'exploitation du sillon conformément au contrat. Il est mis à jour dans la base de données des avis de restriction fournie par le GI. Par conséquent, il n'existe aucune interface directe entre cette STI et celle relative à l'infrastructure.
4.3.2. Interfaces avec la STI «Contrôle-commande et signalisation»
Les seuls liens qui peuvent être établis avec la STI «Contrôle-commande et signalisation» sont assurés via:
— |
le contrat relatif au sillon, qui fournit des informations sur l'équipement de contrôle-commande et de signalisation utilisable dans le segment de ligne concerné, et |
— |
les bases de données de référence du matériel roulant, qui contiennent les données relatives à l'équipement de contrôle-commande et de signalisation du matériel roulant. |
4.3.3. Interfaces avec le sous-système «Matériel roulant»
Le sous-système «Applications télématiques au service du fret» contient les données techniques et opérationnelles qui doivent être disponibles concernant le matériel roulant.
La STI «Matériel roulant» définit les caractéristiques des wagons. Lorsque celles-ci sont modifiées, les bases de données de référence du matériel roulant doivent être mises à jour conformément à la procédure applicable en matière de maintenance des bases de données. Il n'existe par conséquent aucune interface directe entre la présente STI et celle sur le «Matériel roulant».
4.3.4. Interfaces avec la STI «Exploitation et gestion du trafic»
Le sous-système «Exploitation et gestion du trafic» précise les procédures et l'équipement concerné pour garantir la cohérence de l'exploitation des différents sous-systèmes structurels, dans des situations normales ou exceptionnelles, et porte essentiellement sur la conduite des trains et sur la planification et la gestion du trafic.
Le sous-système «Applications télématiques au service du fret» définit principalement les applications relatives aux services de fret, notamment le contrôle en temps réel des marchandises et des trains et la gestion des liaisons avec les autres modes de transport.
Par souci de cohérence entre les deux STI, on applique la procédure suivante.
Lorsque les spécifications de la STI «Exploitation et gestion du trafic» liées aux dispositions de la présente STI seront rédigées et/ou modifiées, il sera nécessaire de consulter l'organisme chargé de cette STI.
De même, en cas de modification des spécifications de cette STI liées aux dispositions définies dans la STI «Exploitation et gestion du trafic», l'organisme chargé de cette dernière devra être consulté.
4.4. Règles d'exploitation
Les règles d'exploitation propres au sous-système concerné par la présente STI en fonction des exigences essentielles décrites au chapitre 3 sont présentées ci-dessous.
4.4.1. Qualité des données
Pour garantir la qualité des données, l'auteur d'un message se porte garant de l'exactitude de son contenu au moment de l'envoi de celui-ci. Si ces données sont disponibles dans les bases de données liées à la STI, il convient de les utiliser pour garantir la qualité de celles-ci.
Si elles ne s'y trouvent pas, l'auteur du message doit vérifier leur fiabilité par ses propres moyens.
Il importe également de les comparer, si nécessaire, avec les informations contenues dans les bases de données liées à la STI et de vérifier la pertinence et la continuité des données et des messages.
Les données sont de grande qualité lorsqu'elles conviennent à l'usage auquel elles sont destinées, c'est-à-dire:
— |
lorsqu'elles sont sans erreurs: accessibles, précises, ponctuelles, complètes, cohérentes avec d'autres sources, etc., et |
— |
lorsqu'elles répondent aux critères requis: pertinentes, complètes, suffisamment précises, faciles à lire et à interpréter, etc. |
La qualité repose sur les critères essentiels suivants:
— |
précision, |
— |
exhaustivité, |
— |
cohérence, |
— |
ponctualité. |
Précision
La collecte des informations doit être la plus économique possible. À cet effet, les données primaires, qui jouent un rôle décisif dans l'acheminement d'une marchandise, d'un wagon ou d'un conteneur, doivent être enregistrées une seule fois, si possible, pour l'ensemble du parcours. C'est pourquoi elles doivent être introduites dans le système en se basant autant que possible sur leur source, comme la lettre de voiture liée au wagon ou à la marchandise, afin qu'elles puissent être utilisées par la suite tout au long du parcours
Exhaustivité
Avant d'envoyer le message, il faut en vérifier l'exhaustivité et la syntaxe sur la base des métadonnées. Cela évite la circulation d'informations inutiles sur le réseau.
L'exhaustivité de tous les messages entrants doit également être vérifiée sur la base des métadonnées.
Cohérence
La cohérence des messages doit être garantie en appliquant les règles commerciales. Il faut éviter les doubles entrées et s'assurer que le détenteur des données est clairement identifié.
Le mode d'application de ces règles dépend de leur complexité. Pour les règles simples, les contraintes et les dispositions relatives aux bases de données suffisent. Lorsque les règles sont plus complexes et impliquent des données issues de plusieurs tableaux, il faut appliquer des procédures de validation afin de vérifier la cohérence des données avant de créer les données d'interface et de les diffuser. Il faut aussi vérifier que la validation des données transmises respecte les règles commerciales définies.
Ponctualité
Il importe de fournir les informations à temps. Dans la mesure où l'enregistrement des données et l'envoi des messages dépendent directement du système de communication, la ponctualité ne pose aucun problème lorsque le système est bien conçu, en fonction des besoins du processus commercial. Cependant, dans la plupart des cas, l'envoi du message est effectué par un opérateur ou, du moins, implique l'intervention d'un opérateur (par exemple l'envoi de la composition du train ou l'actualisation des données relatives au train ou au wagon). Pour satisfaire au critère de ponctualité, les données doivent être mises à jour dans les plus brefs délais afin de garantir l'exactitude du contenu des messages envoyés automatiquement par le système.
En règle générale, les conditions suivantes doivent être respectées.
Le délai de réponse aux demandes de renseignements ne doit pas dépasser 5 minutes. L'actualisation et les échanges des données doivent être effectués dans les plus brefs délais. Le temps de réaction du système et de transmission des données en vue de leur mise à jour ne doit pas dépasser une minute.
Mesure de la qualité des données
S'agissant de l'exhaustivité des données obligatoires (pourcentage de champs de données complétés) et de la cohérence des données (pourcentage de correspondance des données dans les tableaux et fichiers), le pourcentage requis est de 100 %.
Concernant la ponctualité des données (pourcentage de données disponibles dans un délai donné), le pourcentage doit atteindre 98 %. Dans la mesure où cette STI ne définit aucune valeur limite, celles-ci doivent être fixées dans le contrat entre les parties concernées.
La précision requise (pourcentage d'exactitude des valeurs enregistrées par rapport aux valeurs réelles) doit dépasser 90 %. Les valeurs exactes et les critères doivent être définis dans le contrat entre les parties concernées.
4.4.2. Gestion du répertoire central
Les fonctions du répertoire central sont définies dans au point 4.2.14.6 «Répertoire central». Pour garantir la qualité des données, l'organisme chargé de sa gestion doit être responsable de l'actualisation et de la qualité des métadonnées et du répertoire, ainsi que de la gestion du contrôle d'accès (clé publique). S'agissant de la qualité des métadonnées, leur exhaustivité, leur cohérence, leur ponctualité et leur précision doit atteindre un pourcentage de 100 %.
4.5. Règles de maintenance
Les règles de maintenance propres au sous-système concerné par la présente STI en fonction des exigences essentielles sont présentées au chapitre 3.
Il est nécessaire de garantir la qualité des services de transport même en cas de panne totale ou partielle de l'équipement de traitement des données. Il est par conséquent conseillé d'installer des systèmes ou des ordinateurs de secours extrêmement fiables, qui garantiront la continuité du service durant les réparations.
Les aspects liés à la maintenance des bases de données sont mentionnés au point 4.2.12.3 «Dispositions supplémentaires relatives aux bases de données» (10 et 21).
4.6. Qualifications professionnelles
Les qualifications professionnelles du personnel requises pour l'exploitation et la maintenance du sous-système et pour la mise en œuvre de la STI sont les suivantes.
La mise en œuvre de cette STI ne requiert ni l'acquisition d'un nouveau matériel informatique ou de nouveaux logiciels, ni de nouveaux effectifs. Elle ne donne lieu qu'à des modifications, à des mises à jour ou à une extension des opérations effectuées par le personnel existant. Par conséquent, aucune disposition supplémentaire n'est adjointe aux législations nationales et européenne relatives aux qualifications professionnelles.
La formation complémentaire du personnel, si elle est nécessaire, ne doit pas se limiter à l'apprentissage du fonctionnement de l'équipement. Le personnel doit aussi connaître et comprendre le rôle particulier qu'il joue dans le système de transport. Il doit en particulier être conscient de la nécessité de maintenir un niveau élevé de qualité du travail, car il s'agit d'un élément déterminant pour la fiabilité des informations qui devront être traitées ultérieurement.
Les qualifications professionnelles nécessaires dans la composition et l'exploitation des trains sont définies dans la STI «Exploitation et gestion du trafic».
4.7. Conditions de santé et de sécurité
Les conditions de santé et de sécurité du personnel à respecter lors de l'exploitation et de la maintenance du sous-système concerné (ou le domaine d'application technique défini au point 1.1) et de la mise en œuvre de la STI sont les suivantes:
Aucune disposition supplémentaire n'est adjointe aux législations nationales et européenne relatives à la santé et à la sécurité.
4.8. Registres de l'infrastructure et du matériel roulant
En vertu de l'article 24, paragraphe 1, de la directive 2001/16/CE, «les États membres veillent à ce que les registres de l'infrastructure et du matériel roulant soient publiés et mis à jour chaque année. Ces registres présentent, pour chaque sous-système ou parties de sous-systèmes concernés, les caractéristiques principales et leur concordance par rapport aux caractéristiques prescrites par les STI applicables. Dans ce but, chaque STI indique avec précision quelles informations doivent figurer aux registres de l'infrastructure et du matériel roulant.»
Étant donné que ces registres sont mis à jour et publiés sur une base annuelle, ils ne peuvent être utilisés pour le sous-système «Applications télématiques au service du fret». C'est la raison pour laquelle il n'y a aucun élément à indiquer dans ces registres concernant cette STI.
5. CONSTITUANTS D'INTEROPÉRABILITÉ
5.1. Définition
Selon l'article 2, point d), de la directive 2001/16/CE:
les constituants d'interopérabilité sont «tout composant élémentaire, groupe de composants, sous-ensemble ou ensemble complet de matériels incorporés ou destinés à être incorporés dans un sous-système, dont dépend directement ou indirectement l'interopérabilité du système ferroviaire transeuropéen conventionnel. La notion de “constituant” recouvre des objets matériels mais aussi immatériels, comme les logiciels.»
5.2. Liste des constituants
Les constituants d'interopérabilité sont couverts par les dispositions de la directive 2001/16/CE.
Aucun constituant d'interopérabilité ne concerne le sous-système «Applications télématiques au service du fret».
La mise en œuvre de cette STI ne requiert qu'un équipement informatique standard et ne nécessite pas de dispositions particulières en matière d'interopérabilité dans le secteur ferroviaire. Il s'agit d'un matériel informatique et de logiciels standard, tels qu'un système d'exploitation et des bases de données. Le logiciel d'application est propre à chaque utilisateur et peut être adapté et amélioré suivant la fonctionnalité et les besoins de chaque site. L'«architecture d'intégration de l'application» proposée tient compte du fait que les applications ne disposent pas du même modèle d'information interne. L'intégration de l'application se définit comme le processus permettant la coordination de systèmes d'application de conception différente.
5.3. Performances et spécifications des constituants
Voir le point 5.2. Ne s'applique pas à la STI «Applications télématiques au service du fret».
6. ÉVALUATION DE LA CONFORMITÉ ET/OU DE L'APTITUDE À L'EMPLOI DES CONSTITUANTS ET VÉRIFICATION DU SOUS-SYSTÈME
6.1. Constituants d'interopérabilité
6.1.1. Procédures d'évaluation
La procédure d'évaluation de la conformité ou de l'aptitude à l'emploi des constituants d'interopérabilité doit reposer sur les spécifications européennes ou sur celles adoptées au titre de la directive 2001/16/CE.
S'agissant de l'aptitude à l'emploi, ces spécifications indiquent les paramètres à évaluer, à contrôler ou à observer, et décrivent les méthodes d'essai et les procédures d'évaluation à appliquer, que ce soit sur une plate-forme d'essai ou sur le terrain.
Procédures d'évaluation de la conformité et/ou de l'aptitude à l'emploi:
Liste des spécifications, description des méthodes d'essai:
|
Ne s'appliquent pas à la STI «Applications télématiques au service du fret». |
6.1.2. Module
À la demande du fabricant ou de son représentant installé dans la Communauté, la procédure est menée par un organisme notifié conformément aux dispositions des modules concernés décrits dans la décision 93/465/CEE du Conseil, tels qu'ils sont définis, modifiés et complétés dans l'annexe à la présente STI.
Les modules doivent être associés et utilisés en fonction du constituant concerné.
|
Ne s'applique pas à la STI «Applications télématiques au service du fret». |
6.2. Sous-système «Applications télématiques au service du fret»
À la demande de l'entité adjudicatrice ou de son mandataire dans la Communauté, l'organisme notifié met en œuvre la procédure de vérification «CE» conformément à l'annexe VI de la directive 2001/16/CE.
En vertu de l'annexe II de la directive 2001/16/CE, les sous-systèmes sont répartis en domaines de nature structurelle et fonctionnelle.
L'évaluation de la conformité est obligatoire pour la STI en ce qui concerne le domaine structurel. Le sous-système «Applications télématiques au service du fret» relève du domaine fonctionnel. La présente STI ne définit aucun module pour l'évaluation de la conformité.
Le répertoire central et l'interface commune à chaque nœud de participants forment l'épine dorsale de l'intégration de l'application. Le modèle d'échange d'informations est contenu dans le répertoire central d'intégration de l'application, qui contient les métadonnées de l'interface à un point donné. Les métadonnées contiennent des informations sur le contenu de la communication (de ce qui est envoyé), l'identité des points de communication et les protocoles commerciaux au niveau de l'application propres au processus d'intégration.
Les points suivants sont mis en évidence:
— |
Le répertoire central contient le répertoire (annuaire) de tous les participants à l'échange de messages. Celui-ci doit être mis à jour en permanence. Les erreurs sont décelées immédiatement et ne nécessitent dès lors pas de procédure d'évaluation. |
— |
Le répertoire central héberge l'organisme de certification. Il s'agit essentiellement de la mise en œuvre d'une disposition administrative. Les erreurs sont décelées immédiatement et ne nécessitent dès lors pas de procédure d'évaluation. |
— |
Le répertoire central contient les métadonnées relatives aux messages (conformément à l'annexe A, index 1), qui servent de base aux échanges de messages effectués dans un environnement hétéroclite. Elles doivent être gérées et mises à jour dans ce répertoire. Toute incompatibilité dans la structure des messages ou leur contenu sera décelée immédiatement et le transfert sera refusé. Aucune procédure d'évaluation n'est nécessaire. |
— |
L'interface commune à chaque nœud de participants contient principalement le «miroir» local du répertoire central, qui sert à raccourcir les délais de réponse et à réduire l'occupation du répertoire. Il faut veiller à ce que les versions des données dans ce répertoire et dans l'interface commune soient toujours identiques. Pour ce faire, il faut mettre au niveau central à jour les données et télécharger les nouvelles versions à partir de ce niveau. Aucune procédure d'évaluation n'est nécessaire. |
7. MISE EN ŒUVRE
7.1. Modalités d'application de la présente STI
7.1.1. Introduction
La présente STI a pour objectif de fournir des informations dans le cadre du processus commercial lié au fret ferroviaire et d'améliorer ainsi considérablement la qualité des services de transport. Dans ce contexte, son application n'est aucunement liée aux notions de création, de mise à jour ou d'antériorité de l'infrastructure ou du matériel roulant, contrairement aux autres STI définies dans la directive 2001/16/CE.
En raison de son applicabilité générale, la présente STI exercera une influence considérable sur les processus commerciaux et fonctionnels du secteur ferroviaire en Europe. En outre, la croissance continue du transport de fret international requiert une gestion de l'information à l'échelle européenne. Ces constats justifient l'élaboration d'un plan européen de mise en œuvre de cette STI. Ce plan devrait donner un aperçu des avantages qu'elle devrait procurer, ainsi que de la méthode et d'un calendrier de transition permettant de passer du cadre actuel où coexistent des systèmes d'informations fragmentés à une autoroute de l'information globale et unique au niveau européen, qui devrait apporter une valeur ajoutée à l'ensemble des parties prenantes du secteur ferroviaire: les gestionnaires de l'infrastructure, les entreprises ferroviaires, les transitaires et, enfin, les clients.
Dans ce contexte, un plan de déploiement stratégique européen (SEDP) a été conçu. Il définit le système qui devra être élaboré pour permettre la mise en œuvre de cette STI et du plan de développement qui la sous-tend, décrit ci-dessous.
7.1.2. Plan de déploiement stratégique européen (SEDP)
7.1.2.1. Objectifs du SEDP
Le SEDP poursuit trois objectifs:
1. |
élaborer un plan de mise en œuvre de la STI «Applications télématiques au service du fret» dans le secteur ferroviaire européen; |
2. |
déterminer la faisabilité économique et technique de ce plan; |
3. |
établir une feuille de route des activités nécessaires à son exécution. |
En outre, le SEDP doit définir les critères appropriés qui permettront aux différentes parties prenantes (les gestionnaires de l'infrastructure, les entreprises ferroviaires, les transitaires et les clients) de contrôler l'évolution de ce processus de manière à garantir au mieux la défense de leurs intérêts. Ces critères portent notamment sur les investissements qui doivent être consentis par les gestionnaires de l'infrastructure et les entreprises ferroviaires dans la mise à jour et l'intégration potentielles de leurs systèmes informatiques et dans l'amélioration des capacités des systèmes concernés par la présente STI à répondre efficacement aux besoins d'information grandissants des transitaires et des clients.
Dans ce contexte, le SEDP doit devenir à terme un instrument sur la base duquel l'ensemble du secteur ferroviaire européen s'attachera à mettre au point un système d'information à dimension européenne, tout en évitant sa fragmentation en différents systèmes et en garantissant la promotion de synergies et la focalisation des moyens limitées sur les priorités qui répondent le mieux aux objectifs de qualité primordiaux des services de transport.
7.1.2.2. Les conditions de mise en œuvre du SEDP
L'élaboration de ce plan requiert une analyse systématique des questions techniques, opérationnelles, économiques et institutionnelles qui sous-tendent le processus de mise en œuvre de la STI «Applications télématiques au service du fret» (ATF). Elle prévoit notamment:
1. |
l'inventaire des applications informatiques existantes susceptibles de servir de base à la conception d'un système paneuropéen capable de satisfaire aux exigences de la présente STI (dénommé ci-après le système ATF); |
2. |
la définition des données fonctionnelles et de celles qui y sont associées, ainsi que des critères d'efficacité nécessaires à la mise en œuvre de la STI; |
3. |
l'esquisse de l'architecture du système ATF, qui doit se fonder sur l'analyse des configurations du système permettant d'intégrer potentiellement le matériel informatique existant tout en garantissant la fonctionnalité et l'efficacité requises. Il s'agit par exemple d'architectures centralisées ou réparties entre clients et serveurs, ou encore d'architectures basées sur des agents; |
4. |
la définition des critères techniques, concernant notamment l'interface, du système ATF et de ses sous-systèmes potentiels orientés vers le client; |
5. |
l'élaboration d'un plan de développement global du système ATF, de sa conception à sa mise en œuvre effective. Ce plan devra définir des lignes directrices pour la planification et l'exécution de l'intégration des installations existantes et présenter une évaluation des risques liés à ses étapes cruciales. En outre, il devra rendre compte de l'évolution actuelle et future de ces installations; |
6. |
la détermination des structures de gouvernance nécessaires à la mise en œuvre du système ATF et à son utilisation; |
7. |
une évaluation des coûts totaux du cycle de vie (CCV) liés au développement et au fonctionnement du système ATF, ainsi que le plan d'investissement qui en découle. |
Cette analyse ne doit pas être effectuée qu'une seule fois. Elle devra être menée à plusieurs reprises afin de déterminer la meilleure stratégie de déploiement du système. Elle devrait aboutir aux résultats suivants:
— |
un ensemble complet de spécifications fonctionnelles, techniques et relatives à l'efficacité aux fins d'acquisition du système ATF, |
— |
un programme de développement couvrant toutes les étapes, de la conception à la mise en œuvre effective. Il devra inclure la planification précise de toutes les étapes du projet et des principales activités de tous les acteurs qui interviennent dans ce processus, |
— |
une définition de la structure de gouvernance, des méthodes et des procédures ( (7)) qui sous-tendent la mise au point, la validation et le fonctionnement du système, |
— |
un plan d'investissement et le montage financier qui devra permettre son élaboration. |
7.1.3. Modalités de mise en œuvre
Les modalités de mise en œuvre de la présente STI sont soumises aux conditions du plan de déploiement stratégique européen (SEDP), définies ci-dessus.
L'élaboration du SEDP nécessite les conditions suivantes:
— |
les entreprises ferroviaires et les gestionnaires de l'infrastructure devront apporter leur contribution en fournissant des informations fonctionnelles et techniques sur leurs applications télématiques respectives dans le domaine du fret ( (8)), |
— |
les organismes représentatifs du secteur ferroviaire au niveau européen, tels qu'ils sont visés à l'article 3, paragraphe 2, du règlement (CE) no 881/2004, devront élaborer un plan de déploiement stratégique européen, tel qu'il est défini ci-dessus. Ils devront transmettre ce plan stratégique aux États membres et à la Commission dans un délai d'un an à compter de la date de publication du présent règlement. Si aucun progrès substantiel n'est effectué à la fin de cette période, la Commission européenne rédigera des propositions législatives relatives à la mise en œuvre de la présente STI, |
— |
dès que le plan stratégique sera achevé, toutes les activités liées à la mise en œuvre du sous-système «Applications télématiques au service du fret» devront se baser sur ce plan de déploiement. Les EF ou les GI qui ne souhaitent pas y adhérer devront justifier leur position dans le dossier de mise en œuvre remis à l'État membre, à l'Agence ferroviaire européenne et à la Commission européenne. |
7.2. Stratégie de transition
Une stratégie devra être adoptée afin de garantir la transition entre la situation actuelle, avec ses systèmes d'information multiples, et la mise en œuvre de la STI définie dans le SEDP.
Afin de faciliter cette transition, la STI contient des concepts de traitement des informations. Ils sont conçus de manière à permettre une mise en œuvre progressive du système paneuropéen relatif à la présente STI, en prévoyant notamment un système de communication de «poste à poste» ou encore des répertoire de données agrégées (c'est-à-dire qui contient les métadonnées des messages et un répertoire des données et qui héberge l'organisme de certification).
Voici un exemple de la mise en pratique de ce type d'échanges entre une EF et un GI. Il illustre uniquement les liens de communication logiques entre les systèmes, structurés en étapes, et ne rend pas compte des besoins éventuels des différents systèmes pour garantir la transition. Ces besoins devront être dûment pris en considération lors de l'élaboration du SEDP.
Étape 1: l'architecture générale, telle qu'elle est définie au point 4.2.14.1 «Architecture générale», nécessite un «répertoire central» géré par un organisme neutre et indépendant. Tous les sites des participants au réseau de communication sont pourvus d'une couche d'interface, éventuellement munie d'un courtier de messages, qui est spécialement conçue pour l'interopérabilité, qu'elle soit centrale ou individuelle. Il s'agit en l'occurrence de respecter les prescriptions de «la mise en réseau et la communication», les seuls aspects opérationnels indispensables à l'interopérabilité. Ces prescriptions constituent en outre les conditions de base préalables à la mise en place d'un système d'échange de données au niveau européen. C'est pourquoi elles doivent être respectées et mises en œuvre avant toute autre étape.
Une fois cette étape terminée, il est déjà possible de transmettre des documents par voie électronique (point 4.2.13 «Transmission électronique de documents») indépendamment de la succession logique des autres étapes.
Niveau de mise en œuvre atteint à l'issue de cette étape |
|||||
par le GI |
par l'EF |
||||
La base de l'échange d'informations est créée. Avantages
|
Étape 2: parallèlement à la première étape ou à sa suite, il faut créer les bases de données de référence de matériel roulant et la base de données opérationnelle des wagons et des unités intermodales (point 4.2.11.3 «Bases de données de référence du matériel roulant» et point 4.2.12.2 «Autres bases de données»). Si toutes les données ne se trouvent pas encore dans les bases de données, il doit être au moins possible d'insérer manuellement dans la base de donnée opérationnelle des wagons et des unités intermodales les informations relatives aux différents wagons et nécessaires à l'exploitation du train, telles qu'elles sont énumérées dans l'annexe A, index 2.
Niveau de mise en œuvre atteint à l'issue de cette étape |
|||||
par le GI |
par l'EF |
||||
Les données de base propres aux bases de données susmentionnées sont accessibles et peuvent être mises à jour manuellement. Avantages
|
Étape 3: pour accéder aux bases de données depuis l'extérieur, l'interface commune doit être rendue opérationnelle parallèlement à la deuxième étape ou immédiatement après.
Niveau de mise en œuvre atteint à l'issue de cette étape |
|||||||
par le GI |
par l'EF |
||||||
Mise au point d'une base de données relative aux sillons et aux trains. L'ajout de données peut se faire manuellement. Il est désormais possible de se connecter aux systèmes existants utilisés par les GI pour ajouter des données et les mettre à jour automatiquement. Avantage
|
La(Les) base(s) de données relatives aux mouvements des wagons/unités intermodales et au chargement (poids, marchandises dangereuses), ainsi que les fichiers de référence, sont en cours de préparation. Désormais, les informations issues des lettres de voiture (demandes de wagons) et/ou relatives à la composition du train peuvent être ajoutées manuellement ou automatiquement via la connexion interne de l'EF aux systèmes d'enregistrement des lettres de voiture et de la composition du train. Il est désormais possible de comparer les données sur les wagons à celles présentes dans les bases de données de référence du matériel roulant, de même que de vérifier la compatibilité entre les données relatives aux trains et celles liées à l'infrastructure. Avantages
|
À propos des étapes ultérieures, il importe de mentionner que l'architecture proposée est conçue pour permettre une application progressive des différentes fonctions, de manière à respecter, à terme, les exigences du sous-système «Applications télématiques au service du fret». À partir du répertoire central (métadonnées relatives aux messages, répertoire et organisme de certification), il est possible de procéder à l'échange d'informations entre deux partenaires, en fonction du type de message impliqué.
Étape 4: la procédure relative aux messages de demande de sillon peut être appliquée indépendamment des étapes suivantes. Toutefois, dès l'étape 6, il sera nécessaire que le sillon soit déjà désigné par un numéro.
Niveau de mise en œuvre atteint à l'issue de cette étape |
|||||
par le GI |
par l'EF |
||||
Les bases de données relatives aux sillons et aux trains sont complétées automatiquement. Les sillons sont attribués sur la base d'une application télématique, grâce aux bases de données des avis de restriction d'infrastructure. Avantages
|
Il est possible de demander des sillons à court terme. Avantage
|
Étape 5: les demandes de wagons contiennent des informations utiles à la composition du train, raison pour laquelle ces messages doivent être traités avant l'étape 6.
Niveau de mise en œuvre atteint à l'issue de cette étape |
|||||
par le GI |
par l'EF |
||||
Aucun élément supplémentaire |
Les informations relatives à la lettre de voiture sont transférées automatiquement dans les bases de données évoquée dans la troisième étape. Les demandes de wagons sont rédigées et envoyées automatiquement aux autres EF concernées. Avantages
|
Étape 6: il s'agit de l'application des messages liés à la préparation du train, le principal étant celui sur la composition du train, qui doit ainsi être réalisé en premier lieu.
Niveau de mise en œuvre atteint à l'issue de cette étape |
|||||||||||
par le GI |
par l'EF |
||||||||||
La composition du train est connue à l'avance, les données sont plus fiables, l'horodatage attestant de l'heure de début d'utilisation du sillon est précis, la base de données relative aux sillons et aux trains est mise à jour automatiquement. Avantage
|
La composition du train est en général envoyée automatiquement, les données sont très fiables, les bases de données décrite à la troisième étape sont mises à jour automatiquement. Avantages
|
Étape 7: au plus tard avant la huitième étape, il est nécessaire que les EF garantissent la mise en œuvre des fonctions relatives aux mouvements des wagons (avis de libération du wagon et avis de départ, arrivée du wagon au dépôt, départ du wagon du dépôt, avis d'arrivée du wagon, avis de livraison du wagon et confirmation de la livraison), ainsi que de celle relative au plan d'acheminement.
Niveau de mise en œuvre atteint à l'issue de cette étape |
|||
par le GI |
par l'EF |
||
Aucun élément supplémentaire |
Il est désormais possible de mettre en œuvre le plan d'acheminement des wagons et des unités intermodales à l'aide de l'application informatique. Le système est configuré de manière à calculer les mouvements des wagons et des unités intermodales, et à envoyer et recevoir des messages à leur sujet. Avantage
|
Étape 8: cette étape concerne les messages relatifs à la circulation du train et aux prévisions de circulation. Grâce au message de prévision de circulation du train, il est possible d'envoyer le message d'heure d'arrivée prévue du convoi (HAPT et temps de transfert prévu), qui sert de base au calcul des HEP et des HAP des wagons/cargaisons. Cette prévoit également la procédure de questions/réponses relative à la circulation du train et aux prévisions de circulation.
Niveau de mise en œuvre atteint à l'issue de cette étape |
|||||||||||||||
par le GI |
par l'EF |
||||||||||||||
Les messages «circulation du train» et «prévision de circulation» sont envoyés en temps réel aux GI et aux EF concernés. Avantages
|
Possibilité de calculer les HEP/HAP des wagons/cargaisons grâce aux heures d'arrivée prévues aux différents points. Avantages
|
Étape 9: les rapports d'échange (point 4.2.9 «Rapports d'échanges») et la fonction présentée au point 4.2.7 «HEP/HAP de la cargaison» doivent être mis en œuvre parallèlement à la huitième étape ou immédiatement après. Cette étape concerne en particulier les EF.
Niveau de mise en œuvre atteint à l'issue de cette étape |
|||||||||||||||
par le GI |
par l'EF |
||||||||||||||
Elle permet de connaître l'emplacement du wagon sur l'infrastructure du GI et l'EF responsable, même si le wagon n'est pas arrimé à un train. Avantage
|
Cette étape permet de calculer la HEP et la HAP sur la base de la HAPT, et de mettre à jour automatiquement les données relatives aux mouvements dans la base de données opérationnelle des wagons et des unités intermodales. Elle permet la gestion complète des wagons vides et la planification de l'acheminement au niveau international. Avantages
|
Étape 10: cette étape porte sur la mise en œuvre de la fonction «informations d'interruption de service», ainsi que sur la procédure de questions/réponses relative aux retards des trains, à leurs identifiants et à leur emplacement. Ces informations permettent d'envoyer les messages relatifs aux incidents aux EF (point 4.2.8.6 «Message de notification d'incident» et point 4.2.8.7 «Message de notification d'incident: demande d'une nouvelle HEP/HAP»).
Niveau de mise en œuvre atteint à l'issue de cette étape |
|||||||
par le GI |
par l'EF |
||||||
Le GI transmet des informations sur les incidents aux EF. Avantage
|
Les incidents sont traités et des enquêtes sont ouvertes. Avantage
|
Étape 11: après une phase de consolidation, cette étape consiste à évaluer les données transmises et enregistrées.
Niveau de mise en œuvre atteint à l'issue de cette étape |
|||
par le GI |
par l'EF |
||
Disponibilité de bases de données statistiques exhaustives Avantage
|
7.3. Gestion des modifications
7.3.1. Introduction
Le concept de mise à jour est propre à tous les types de systèmes informatiques. Il résulte de l'apparition de nouvelles spécifications et de modifications apportées à celles qui existent déjà, soit en raison d'erreurs repérées en cours de fonctionnement, soit parce qu'il est nécessaire d'améliorer les performances ou d'autres caractéristiques non liées au fonctionnement des systèmes.
Néanmoins, les mises à jour doivent être gérées convenablement, car elles sont indispensables à la continuité du service et aux objectifs de compatibilité, afin de réduire au maximum les frais généraux de l'exploitation de l'équipement informatique utilisé dans les applications télématiques et de réduire au maximum le temps de transition. Il importe par conséquent de définir une stratégie précise sur le mode de mise à jour de l'équipement informatique sans entraver la continuité du service et l'interopérabilité. Deux dispositions importantes sous-tendent la définition de cette stratégie:
— |
la création d'un système de gestion de la configuration, qui établit des normes et des procédures de gestion de l'évolution du système. Il doit définir le mode d'enregistrement et de traitement des propositions de modification et la manière de lier ces modifications aux éléments du système et d'assurer le suivi de leur diffusion, |
— |
la mise en œuvre d'une stratégie relative à la diffusion des lignes de base du système. |
7.3.2. Lignes de base
La stabilité du système est indispensable à sa mise en œuvre et à son déploiement. Cela s'applique à toutes les parties prenantes:
— |
les gestionnaires de l'infrastructure et les entreprises ferroviaires, qui devront utiliser différentes versions du système, |
— |
le secteur concerné, qui a besoin de temps pour préciser, concevoir et tester l'interopérabilité permanente. |
La ligne de base incarne essentiellement la notion de noyau stable s'agissant de la fonctionnalité, des performances et d'autres caractéristiques non liées au fonctionnement du système (par ex. RAM) ( (9)). Toutefois, l'expérience de ce type de système montre que plusieurs versions différentes ( (10)) sont nécessaires avant de parvenir à une ligne de base stable et appropriée à la mise en œuvre souhaitée, comme le montre le graphique ci-dessous.
Grâce à ce système de retour d'informations, ce procédé présente une grande interconnexion, ce qui évite de devoir mettre plusieurs procédés en parallèle, une démarche qui entraînerait de l'instabilité et de la confusion et perturberait le fonctionnement. Les lignes de base doivent ensuite être abordées les unes après les autres et non en parallèle, comme l'illustre le graphique suivant:
7.3.3. Diffusion des lignes de base
L'expérience permet d'estimer la durée de l'intervalle entre deux lignes de base à environ quatre ou cinq ans.
La nouvelle ligne de base doit en principe contenir les modifications majeures apportées à la fonctionnalité ou à la performance du système. Il peut s'agir de:
— |
l'incorporation d'un ensemble de fonctions actuelles au niveau national, qui peuvent être généralisées via le noyau interopérable, |
— |
d'autres services à valeur ajoutée. |
Chaque ligne de base doit en outre tenir compte de la fonctionnalité de celle qui la précède. Les versions de correction des erreurs de système ou des failles de sécurité doivent être regroupées dans la ligne de base concernée. Sauf pour des raisons de sécurité, les versions présentes dans une même ligne de base doivent être rétrocompatibles.
Cet ajout de fonctionnalité d'une ligne de base à l'autre implique obligatoirement que celles-ci ne sont pas rétrocompatibles. Néanmoins, pour faciliter la transition, il importe de garantir, dans la mesure du possible, un tronc commun de fonctionnalités basées sur la rétrocompatibilité entre les lignes de base, de manière à garantir un niveau de performance admissible des services d'interopérabilité.
7.3.4. Conception de nouvelles lignes de base
Les gestionnaires d'infrastructure et les entreprises ferroviaires ne seront jamais en mesure de passer d'une ligne de base à l'autre du jour au lendemain. C'est pourquoi la conception des lignes de base doit être accompagnée d'une stratégie de transition appropriée, de manière à éviter les problèmes découlant notamment de la coexistence d'applications télématiques différentes compatibles avec des versions différentes des spécifications en question, ou encore résultant des priorités accordées dans le cadre de la transition (aux voies, au matériel roulant ou aux deux) ainsi que de celles accordées à la transition elle-même.
7.3.5. Gestion des modifications — Conditions requises
Comme indiqué précédemment, les mises à jour sont inhérents aux systèmes informatiques de grande envergure. Par conséquent, les procédures de gestion des mises à jour doivent être conçues de manière telle qu'elles garantissent une véritable analyse des coûts et des bénéfices de ces opérations et un contrôle de leur mise en œuvre. Cela nécessite d'adopter une procédure de gestion des mises à jour et des outils appropriés, de façon à garantir leur enregistrement et leur ajout aux spécifications avec un bon rapport de rentabilité. Quelles que soient les dispositions propres à cette procédure, son élaboration doit reposer sur l'approche structurée présentée ci-après:
L'ensemble des normes et des procédures qui sous-tendent la procédure de gestion des mises à jour, telle qu'elle est décrite ci-dessus, doit faire l'objet d'un plan de gestion de la configuration. Les spécifications générales de ce plan sont décrites dans le paragraphe 7.3.6 ci-dessous. La stratégie de mise en œuvre des mises à jour approuvées doit être formalisée (selon les dispositions et sur la base des documents ad hoc) dans le cadre d'un plan de gestion des mises à jour, qui doit notamment préciser:
— |
les contraintes techniques qui sous-tendent les modifications, |
— |
le responsable des procédures de mise en œuvre des modifications, |
— |
la procédure de validation des modifications à appliquer, |
— |
la politique de gestion des modifications, de diffusion, de transition et de développement. |
Un aspect important de la gestion des mises à jour consiste à déterminer les responsabilités concernant l'élaboration des spécifications, la garantie de leur qualité et la gestion de la configuration. La majeure partie de ce travail devrait incomber à l'Agence ferroviaire européenne (crée par le règlement 881/2004/CE) ou être supervisée par elle dès qu'elle sera opérationnelle. La gestion des modifications doit être officialisée par toute une série de documents, cités à l'annexe A.
Enfin, il est indispensable que l'organisme chargé de contrôler les modifications (CCB), qui exercera à terme une autorité sur l'ensemble du système, se compose de mandataires de toutes les parties prenantes: les gestionnaires de l'infrastructure, les entreprises ferroviaires, leurs fournisseurs, les organismes notifiés et les autorités de contrôle. Cette implication des parties prenantes doit garantir la prise en considération générale des modifications à apporter ainsi qu'une évaluation globale de leurs conséquences. Le CCB sera, à terme, placé sous l'égide de l'Agence ferroviaire européenne.
7.3.6. Plan de gestion de la configuration — conditions requises
Le plan de gestion de la configuration doit définir les normes et les procédures propres à la gestion des modifications. Il devra préciser:
— |
les entités qui seront gérées, ainsi que le procédé formel d'identification de ces entités, |
— |
le responsable des procédures de gestion de la configuration et de la présentation des entités contrôlées à l'organe décisionnel dans la gestion de la configuration, |
— |
les méthodes de gestion de la configuration à appliquer dans le contrôle des modifications et la gestion des différentes versions, |
— |
une description des fichiers de la procédure de gestion de la configuration qu'il convient de conserver, |
— |
une description des outils à utiliser dans la gestion de la configuration et leur procédure d'utilisation, |
— |
une définition de la base de données de configuration, qui sera utilisée pour enregistrer les informations de configuration. |
Les dispositions particulières des procédures de gestion de la configuration doivent être formalisées par des spécifications qu'il faudra ajouter à la liste déjà présente à l'annexe A de la présente STI.
7.4. Cas spécifiques
7.4.1. Introduction
Les dispositions particulières suivantes sont autorisées dans les cas spécifiques ci-dessous.
Ces cas spécifiques sont répartis en deux catégories de dispositions: permanentes (cas «P») ou temporaires (cas «T»). Dans les cas temporaires, il est recommandé aux États membres concernés de se conformer au sous-système adéquat soit d'ici à 2010 (cas «T1»), objectif inscrit dans la décision 1692/96/CE du Parlement européen et du Conseil du 23 juillet 1996 relative aux orientations communautaires pour le développement du réseau transeuropéen de transport ( (11)), soit d'ici à 2020 (cas «T2»). «T ouvert» est considéré comme une période indéterminée, qui sera précisée lors d'une révision ultérieure de la présente STI.
7.4.2. Liste des cas spécifiques
7.4.2.1. Cas spécifique concernant les États membres de l'UE partageant une frontière commune avec un pays tiers
Sur le territoire des États membres qui partagent une frontière commune avec un pays tiers, les exigences de la STI ne sont pas obligatoires pour les liaisons de transport directes avec les pays tiers (cas «T ouvert»).
Néanmoins, si le trajet doit être prolongé vers un autre État membre, toutes les dispositions de la STI doivent être appliquées, sauf s'il existe un accord bilatéral ou multilatéral entre les États concernés ou les entreprises ferroviaires ou les gestionnaires de l'infrastructure actives sur le territoire de ces États membres.
7.4.2.2. Cas spécifique concernant la Grèce
Pour les trajets effectués sur des voies dont l'écartement est de 1 000 mm, les dispositions nationales ont force de loi.
(1) JO L 75 du 15.3.2001, p. 29. Directive modifiée en dernier lieu par la directive 2004/49/CE (JO L 164 du 30.4.2004, p. 44), rectifiée au JO L 220 du 21.6.2004, p. 16.
(2) JO L 220 du 30.8.1993, p. 23.
(3) JO L 75 du 15.3.2001, p. 26.
(4) JO L 237 du 24.8.1991, p. 25. Directive modifiée en dernier lieu par la directive 2004/51/CE du Parlement européen et du Conseil (JO L 164 du 30.4.2004, p. 164), rectifiée au JO L 220 du 21.6.2004, p. 58.
(5) On entend par point de départ celui du sillon, qui peut être le point de départ effectif du train ou son point de départ à partir d'un point d'échange. Le point de transfert est celui où le sillon se termine.
(6) En d'autres termes, cela signifie que l'accès à ces informations ne peut être lié à celui qu'utilise le GI pour stocker les informations ou une partie de celles-ci.
(7) Par exemple, les normes de garantie de la qualité, la méthodologie d'élaboration du plan, la méthodologie d'expérimentation, la planification des documents, etc.
(8) Il s'agit de toutes les applications télématiques en service avant l'entrée en vigueur de la STI.
(9) La ligne de base tient lieu de point de départ de référence pour la gestion contrôlée de l'évolution du système.
(10) Les versions du système sont celles distribuées aux clients du secteur ferroviaire. Elles peuvent avoir une fonctionnalité et des performances différentes ou corriger les erreurs de système ou les failles de sécurité.
(11) JO L 228 du 9.9.1996, p. 1. Décision modifiée en dernier lieu par la décision 884/2004/CE (JO L 167 du 30.4.2004, p. 1), rectifiée au JO L 201 du 7.6.2004, p. 1
ANNEXE A
LISTE DES DOCUMENTS D'ACCOMPAGNEMENT
Liste des spécifications obligatoires
Index N |
Référence |
Nom du document |
Version |
1 |
AEIF_TAF_MesData_ V11_041021.doc |
Sous-système «Applications télématiques au service du fret» — Définitions et messages relatifs aux données |
1.1 |
2 |
AEIF_TAF_DbsData_ V10_040322.doc |
Sous-système «Applications télématiques au service du fret» — Données d'infrastructure et du matériel roulant |
1.0 |
3 |
AEIF_TAF_ConData_ V10_040622.doc |
Sous-système «Applications télématiques au service du fret» — Description et informations sur la lettre de voiture |
1.0 |
4 |
AEIF_TAF_Patdata_ V10_040622.doc |
Sous-système «Applications télématiques au service du fret» — Description et informations sur les sillons |
1.0 |
5 |
AEIF_TAF_FigSeq_ V10_040622.doc |
Sous-système «Applications télématiques au service du fret» — Illustrations et diagrammes séquentiels relatifs aux messages de la STI ATF |
1.0 |
6 |
AEIF_TAF_CofMgt_ V10_041012.doc En attente |
Gestion de la configuration, notion et conditions générales de la STI ATF |
1.0 |
ANNEXE B
GLOSSAIRE
Terme |
Description |
||||||||||||||||||||||||||||||||||||||||||||||||||
ACID |
Atomicité, cohérence, isolement, durabilité Il s'agit des quatre attributs principaux de toute transaction.
Le concept ACID est défini dans la norme ISO/IEC 10026-1:1992, section 4. Chacun de ses attributs peut être évalué par rapport à un point de référence. En général, la mise en œuvre de ce concept incombe au gestionnaire ou au superviseur de la transaction. Dans un système distribué, elle peut être garantie par une validation en deux phases (2 PC), qui implique que soit toutes les parties prenantes s'engagent à valider la transaction. Dans le cas contraire, celle-ci est supprimée. |
||||||||||||||||||||||||||||||||||||||||||||||||||
AEIF |
Association européenne pour l'interopérabilité ferroviaire. Selon la directive 2001/16/CE, il s'agit de «l'organisme commun représentatif», composé de représentants de l'UIC, de l'UNIFE et de l'UITP. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Candidat |
Toute entreprise ferroviaire agréée et/ou tout regroupement international d'entreprises ferroviaires titulaires d'une licence et, dans les États membres qui prévoient cette possibilité, d'autres personnes physiques ou morales ou entités ayant des raisons commerciales ou de service public d'acquérir des capacités d'infrastructure pour l'exploitation d'un service ferroviaire sur leurs territoires respectifs, comme les autorités publiques visées dans le règlement (CEE) no 1191/69 du Conseil (1) et les chargeurs, les transitaires et les opérateurs de transports combinés. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Capacité unitaire utilisée |
Code indiquant le niveau de chargement du matériel (par ex. plein, vide, incomplet) |
||||||||||||||||||||||||||||||||||||||||||||||||||
Cargaison |
Ensemble de marchandises envoyées par un expéditeur à un destinataire dans une ou plusieurs unités complètes du GI ou qui sont chargées sur un ou plusieurs wagons complets. Exemples: |
||||||||||||||||||||||||||||||||||||||||||||||||||
Charge de wagon |
Chargement unitaire dont l'unité est le wagon. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Chargement unitaire |
Ensemble d'emballages individuels, reliés, palettisés ou cerclés de manière à constituer une seule unité et ainsi à faciliter leur manutention par des moyens mécaniques. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Code NC |
Liste des codes de produits à 8 caractères utilisés par les douanes. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Code SH |
Liste des codes de produits à 6 caractères utilisés par les douanes. Les six premiers caractères sont identiques à ceux du code NC. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Constituant d'interopérabilité |
Tout composant élémentaire, groupe de composants, sous-ensemble ou ensemble complet de matériels incorporés ou destinés à être incorporés dans un sous-système, dont dépend directement ou indirectement l'interopérabilité du système ferroviaire transeuropéen conventionnel. La notion de «constituant» recouvre des objets matériels mais aussi immatériels, comme les logiciels. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Cryptage |
Encodage des messages Décryptage: conversion des données cryptées dans leur forme initiale |
||||||||||||||||||||||||||||||||||||||||||||||||||
Date et heure de libération |
Date et heure auxquelles il est prévu que les marchandises seront libérées ou ont été libérées par le client. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Date et heure de libération des wagons |
Date et heure auxquelles les wagons sont prêts à être tractés à l'emplacement donné sur le site du client donné. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Date/heure de départ réelles |
Date et heure de départ du moyen de transport |
||||||||||||||||||||||||||||||||||||||||||||||||||
Demande de sillon à court terme |
Demande d'un sillon, conformément à l'article 23 de la directive 2001/14/CE, résultant de demandes ou de besoins de transport supplémentaires. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Demande de wagons |
Sous-ensemble de la lettre de voiture contenant les informations nécessaires à une EF pour effectuer le transport sous sa responsabilité jusqu'au transfert à l'EF suivante. Instruction pour le transport de la marchandise concernée. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Destinataire |
Partie qui doit recevoir les marchandises Synonyme: réceptionnaire des marchandises |
||||||||||||||||||||||||||||||||||||||||||||||||||
Détenteur |
Personne qui exploite économiquement, de manière durable, un véhicule en tant que moyen de transport, qu'il en soit propriétaire ou qu'il en ait le droit de disposition, et qui est inscrite en tant que telle dans le registre du matériel roulant. |
||||||||||||||||||||||||||||||||||||||||||||||||||
DEVRAIT |
Ce terme, ou l'adjectif «RECOMMANDÉ», signifie qu'il peut exister, dans des circonstances particulières, des raisons valables pour ignorer un élément particulier, mais il faut dans ce cas comprendre et peser judicieusement l'ensemble des implications avant de choisir une orientation différente. |
||||||||||||||||||||||||||||||||||||||||||||||||||
DOIT |
Ce terme ainsi que les termes «REQUIS» ou «IL FAUT», signifient que la définition est une exigence absolue de la spécification. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Données primaires |
Données de base utilisées pour la saisie d'informations de référence des messages ou pour la fonctionnalité et le calcul de données dérivées. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Échange |
Le transfert du contrôle d'une entreprise ferroviaire à une autre pour des considérations pratiques liées à l'exploitation et à la sécurité, comme par exemple:
|
||||||||||||||||||||||||||||||||||||||||||||||||||
EF |
Voir entreprise ferroviaire |
||||||||||||||||||||||||||||||||||||||||||||||||||
EFP |
Voir entreprise ferroviaire principale |
||||||||||||||||||||||||||||||||||||||||||||||||||
Ensemble de sillons |
Raccordement de plusieurs sillons de train pour étendre le sillon dans le temps et dans l'espace. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Entreprise ferroviaire (EF) |
Toute entreprise à statut privé ou public dont l'activité principale est la fourniture de prestations de transport de marchandises et/ou de voyageurs par chemin de fer, la traction devant obligatoirement être assurée par cette entreprise. Ce terme couvre aussi les entreprises qui assurent uniquement la traction. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Entreprise ferroviaire principale |
EF responsable de l'organisation et de la gestion d'une ligne de transport conformément à ses engagements vis-à-vis du client, dont elle est le seul interlocuteur. Si la chaîne de transport implique plusieurs entreprises ferroviaires, l'EFP est également chargée de la coordination entre elles. Un client peut être, notamment pour le transport intermodal, un intégrateur de services intermodaux. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Exigences essentielles |
Ensemble des conditions décrites à l'annexe III de la directive 2001/16/CE auxquelles doivent satisfaire le système ferroviaire transeuropéen conventionnel, les sous-systèmes et les constituants d'interopérabilité, y compris les interfaces. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Expéditeur |
Partie qui, par un contrat conclu avec un intégrateur de services, expédie ou envoie les marchandises avec le transporteur ou lui en confie le convoyage. Synonymes: chargeur, expéditeur des marchandises. |
||||||||||||||||||||||||||||||||||||||||||||||||||
FDMS |
Voir fiabilité, disponibilité, maintenance, sécurité |
||||||||||||||||||||||||||||||||||||||||||||||||||
Feuille de route |
Document rédigé par le transporteur ou pour son compte et justifiant de l'existence d'un contrat de transport de la cargaison. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Fiabilité, disponibilité, maintenance, sécurité (FDMS) |
Fiabilité: capacité, exprimée mathématiquement, de démarrer et de continuer à fonctionner dans des conditions préalablement définies et sur une période déterminée Disponibilité: temps en service comparé au temps hors service, exprimé mathématiquement Maintenabilité: aptitude d'un système, exprimée mathématiquement, à être remis en service après une défaillance Sécurité: probabilité, exprimée mathématiquement, de déclenchement d'un événement dangereux par le système. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Fret |
Quantité de marchandises identifiable distinctement et devant être transportée d'un expéditeur à un destinataire, par un ou plusieurs modes de transport, comme prescrit dans un document de transport unique (synonyme: marchandise expédiée). |
||||||||||||||||||||||||||||||||||||||||||||||||||
FTP |
Acronyme de File Transfer Protocol (protocole de transfert de fichiers). Protocole de transfert de fichiers entre systèmes informatiques |
||||||||||||||||||||||||||||||||||||||||||||||||||
Gestionnaire de l'infrastructure (GI) |
Voir GI. |
||||||||||||||||||||||||||||||||||||||||||||||||||
GGP |
Acronyme de Gateway to Gateway Protocol (protocole de transfert d'informations entre passerelles) Voir également IP |
||||||||||||||||||||||||||||||||||||||||||||||||||
GI |
Gestionnaire d'infrastructure: tout organisme ou toute entreprise chargé notamment de l'établissement et de l'entretien des infrastructures ferroviaires, voire de la gestion des systèmes de contrôle et de sécurité. Les fonctions de gestionnaire de l'infrastructure sur tout ou partie d'un corridor peuvent être attribuées à plusieurs organismes ou entreprises. (directive 2001/14/CE). |
||||||||||||||||||||||||||||||||||||||||||||||||||
GU |
Guichet unique |
||||||||||||||||||||||||||||||||||||||||||||||||||
Guichet unique (GU) |
Partenariat international entre gestionnaires d'infrastructures ferroviaires proposant un interlocuteur unique aux clients du transport ferroviaire de fret afin:
|
||||||||||||||||||||||||||||||||||||||||||||||||||
HAP |
Heure d'arrivée prévue des wagons sur le site du client |
||||||||||||||||||||||||||||||||||||||||||||||||||
HAPT |
Voir heure d'arrivée prévue du train |
||||||||||||||||||||||||||||||||||||||||||||||||||
HEP |
Heure d'échange prévue des wagons entre deux entreprises ferroviaires |
||||||||||||||||||||||||||||||||||||||||||||||||||
Heure d'arrivée prévue du train |
Estimation de l'heure d'arrivée d'un train à un point spécifique, par exemple point de transfert, point de correspondance, destination du train. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Heure de départ prévue |
Date et heure de départ pour lesquelles le sillon est demandé. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Heure prévue |
Heure prévue la plus précise possible d'arrivée, de départ ou de passage d'un train |
||||||||||||||||||||||||||||||||||||||||||||||||||
Horaire prévu |
Occupation de l'infrastructure ferroviaire définie chronologiquement pour un mouvement de train en pleine voie ou dans les gares. Les modifications d'horaires sont fournies par le GI au moins deux jours avant celui du départ du train de son point d'origine. Cet horaire s'applique à un jour spécifique. Dans certains pays, il est qualifié d'horaire d'exploitation. |
||||||||||||||||||||||||||||||||||||||||||||||||||
HTP |
Heure de transfert prévue d'un train entre deux gestionnaires d'infrastructure |
||||||||||||||||||||||||||||||||||||||||||||||||||
HTTP |
Acronyme de HyperText Transfer Protocol (protocole de transfert de fichiers hypertextes) Il s'agit d'un protocole client/serveur utilisé pour la connexion à des serveurs sur le réseau internet. |
||||||||||||||||||||||||||||||||||||||||||||||||||
ICMP |
Acronyme de Internet Control Message Protocol (protocole de gestion des messages de contrôle) Le protocole ICMP est parfois utilisé par une passerelle (voir GGP) ou un hôte de destination (voir IP) pour communiquer avec un ordinateur source et lui signaler une erreur dans le traitement d'un datagramme, par exemple. Le protocole ICMP utilise le protocole IP en tant que support de base comme s'il s'agissait d'un protocole de niveau supérieur; en réalité, il fait partie intégrante du protocole IP et il doit être mis en œuvre par chaque module IP. Plusieurs situations conduisent à l'envoi de messages ICMP: par exemple, lorsqu'un datagramme ne peut pas atteindre sa destination, lorsque la passerelle n'a pas de mémoire tampon suffisante pour acheminer un datagramme, et lorsqu'elle peut indiquer à l'ordinateur hôte d'envoyer un flux de données par un itinéraire plus court. Le protocole IP (voir cet acronyme) n'est pas conçu pour être d'une absolue fiabilité. Le but de ces messages de contrôle est de fournir un retour d'information sur les problèmes de l'environnement de communication et non de rendre le protocole IP plus fiable. Il n'y a malgré tout aucune garantie de remise d'un datagramme ou de renvoi d'un message de contrôle. Il est possible que certains datagrammes n'arrivent pas à destination et qu'il n'y ait aucun message signalant leur perte. Les protocoles de niveau supérieur qui utilisent le protocole IP doivent appliquer leurs propres procédures de fiabilité si une communication fiable est requise. En général les messages ICMP rendent compte d'erreurs de traitement des datagrammes. Pour éviter une réitération infinie de messages relatifs à d'autres messages etc., aucun message ICMP n'est envoyé à propos de messages ICMP. De même, les messages ICMP ne sont envoyés que dans le cas d'erreurs de traitement de fragments «zéro» des datagrammes fragmentés. (Un fragment «zéro» est un fragment dont le décalage est égal à zéro). |
||||||||||||||||||||||||||||||||||||||||||||||||||
ICP |
Infrastructure à clés publiques |
||||||||||||||||||||||||||||||||||||||||||||||||||
Identifiant de la locomotive |
Numéro d'identification unique d'un engin de traction |
||||||||||||||||||||||||||||||||||||||||||||||||||
Intégrateur de services intermodaux |
Tout organisme ou entreprise qui détient le contrat conclu avec les clients pour le transport d'unités intermodales. Il prépare les feuilles de route, gère les capacités de trains complets, etc. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Internet |
|
||||||||||||||||||||||||||||||||||||||||||||||||||
IP |
Acronyme de Internet Protocol, le protocole du réseau Internet Ce protocole est utilisé pour des services d'échange de datagrammes entre ordinateurs hôtes dans un système de réseaux interconnectés. Les dispositifs de connexion des réseaux sont appelés passerelles. Ces passerelles communiquent entre elles à des fins de contrôle par le biais d'un protocole interpasserelle (GGP). |
||||||||||||||||||||||||||||||||||||||||||||||||||
Itinéraire |
Voie géographique à emprunter d'un point de départ à un point d'arrivée |
||||||||||||||||||||||||||||||||||||||||||||||||||
Lettre de voiture |
Document justifiant de l'existence d'un contrat de transport de fret par un transporteur donné depuis un lieu de départ convenu à un lieu de livraison convenu. Il décrit avec précision les marchandises à transporter. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Lieu de départ |
Lieu de départ prévu ou effectif d'un moyen de transport. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Lieu de destination |
Lieu d'arrivée prévu ou effectif du moyen de transport. Synonyme: lieu d'arrivée |
||||||||||||||||||||||||||||||||||||||||||||||||||
Lieu de livraison |
Lieu de livraison (gare ferroviaire de départ à indiquer). Lieu de transfert de responsabilité du wagon. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Locataire |
Toute personne physique ou morale désignée en tant que telle par le détenteur/propriétaire d'un wagon. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Métadonnées |
Il s'agit de données relatives aux données. Elles décrivent les données, les services logiciels et les autres composants des systèmes d'information d'entreprises. Les définitions de données normalisées, les informations de localisation et d'acheminement, ainsi que la gestion de la synchronisation pour la répartition de données partagées sont autant d'exemples de types de métadonnées. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Mise en service |
Procédure dépendant de l'agrément technique d'un wagon et d'un contrat d'utilisation avec une EF qui permet l'exploitation commerciale de ce wagon. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Mode d'exploitation en accès libre |
Mode d'exploitation des trains qui implique une seule EF chargée de faire circuler le train sur plusieurs infrastructures. Cette entreprise ferroviaire conclut les contrats relatifs aux sillons nécessaires avec tous les GI concernés. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Mode de coopération |
Mode d'exploitation des trains par lequel plusieurs EF coopèrent sous la direction d'une entreprise ferroviaire principale (EFP). Chaque EF impliquée conclut séparément un contrat relatif au sillon requis pour le trajet qui la concerne. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Modèle de référence OSI |
Description normalisée de la manière dont les messages doivent être échangés entre deux points quelconques d'un réseau. Le modèle OSI définit 7 couches de fonctions mises en œuvre à chaque extrémité d'une liaison de communication. Ces couches sont le seul cadre normatif reconnu à l'échelle internationale en matière de communication. |
||||||||||||||||||||||||||||||||||||||||||||||||||
NE DEVRAIT PAS |
Cette expression, ou l'expression «N'EST PAS RECOMMANDÉ» signifie qu'il peut exister, dans les circonstances particulières, des raisons valables pour qu'un comportement particulier soit acceptable, voire utile, mais il importe néanmoins de comprendre et de peser judicieusement l'ensemble des implications avant de mettre en œuvre la conduite décrite par cette étiquette. |
||||||||||||||||||||||||||||||||||||||||||||||||||
NE DOIT PAS |
Cette expression ainsi que l'expression «IL NE FAUT PAS» signifient que la définition est une interdiction absolue de la spécification. |
||||||||||||||||||||||||||||||||||||||||||||||||||
NFS |
Acronyme de Network File System, un protocole de fichiers distribués Le protocole NFS permet, en toute transparence, un accès distant à des systèmes de fichiers partagés sur des réseaux. Il est conçu pour être indépendant de la machine, du système d'exploitation, de l'architecture du réseau, du mécanisme de sécurité et du protocole de transport. Cette indépendance est obtenue grâce à un mécanisme de primitives RPC (Remote Procedure Call, appel de procédure à distance) bâti sur XDR (eXternal Data Representation), un protocole général de représentation externe. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Numéro de sillon |
Numéro du sillon de train concerné |
||||||||||||||||||||||||||||||||||||||||||||||||||
Numéro ONU |
Numéro attribué par les Nations unies aux marchandises dangereuses |
||||||||||||||||||||||||||||||||||||||||||||||||||
Numéro RID |
Numéro de l'OTIF concernant les marchandises dangereuses |
||||||||||||||||||||||||||||||||||||||||||||||||||
OC |
Organisme de certification |
||||||||||||||||||||||||||||||||||||||||||||||||||
Opérateur de terminal intermodal |
Opérateur d'un terminal intermodal, par exemple une passerelle. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Organismes notifiés |
Organismes chargés d'évaluer la conformité ou l'aptitude à l'emploi des constituants d'interopérabilité ou d'instruire la procédure de vérification «CE» des sous-systèmes (directive 91/440/CE) |
||||||||||||||||||||||||||||||||||||||||||||||||||
OSI |
Acronyme de Open Systems Interconnection (interconnexion de systèmes ouverts) Décrit un protocole de communication entre systèmes ouverts sur la base du modèle de référence OSI. Les systèmes ouverts sont capables de communiquer indépendamment des solutions propriétaires. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Parcours |
Représentation spatiale ou temporelle de l'expédition d'un wagon vide ou chargé depuis une gare d'expédition à une gare de destination. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Partie responsable |
Toute personne physique ou morale qui a la responsabilité des risques qu'elle importe sur le réseau ferroviaire, par exemple l'EF. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Parties prenantes |
Toute personne physique ou morale étant raisonnablement concernée par l'exploitation du train. Exemples:
En outre, pour le transport intermodal:
|
||||||||||||||||||||||||||||||||||||||||||||||||||
Passerelle — Point d'accès — Point de passage |
Gare où le chargement change de wagon sur le parcours d'un train avec composé d'unités intermodales. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Période de prédépart |
Il s'agit d'une durée X avant l'heure de départ. Elle commence un certain temps avant l'heure de départ prévue et se termine lorsque celle-ci est atteinte. |
||||||||||||||||||||||||||||||||||||||||||||||||||
PEUT |
Ce terme ou l'adjectif «FACULTATIF» signifie qu'un élément est facultatif. Un fournisseur peut choisir d'inclure l'élément visé pour répondre aux besoins d'un marché particulier ou parce qu'il considère que cet élément apporte un avantage au produit, même s'il est admis qu'un autre fournisseur peut l'omettre. Une application qui ne comprend pas d'option particulière DOIT être conçue de manière à interopérer avec une autre application qui inclut cet élément facultatif, même si cela s'accompagne d'une réduction probable de sa fonctionnalité. dans le même ordre d'idée, une application qui ne comprend pas d'option particulière DOIT être conçue de manière à interopérer avec une autre application qui n'inclut pas cet élément facultatif (sauf bien entendu pour ce qui concerne la fonctionnalité induite par l'option correspondante). |
||||||||||||||||||||||||||||||||||||||||||||||||||
Plan d'acheminement |
Désigne l'itinéraire de référence prévu d'un wagon ou d'une unité intermodale. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Poids brut des marchandises |
Poids (masse) total(e) réservé(e)/réel(le) des marchandises, y compris l'emballage, mais sans les équipements du transporteur. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Point d'échange |
Lieu où la responsabilité des wagons d'un train est transférée d'une EF à une autre. En ce qui concerne l'exploitation du train, une EF transfère la prise en charge du train à l'autre EF qui possède à présent le sillon pour la section suivante du trajet. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Point d'observation |
Lieu, sur le parcours du train, où le GI responsable doit envoyer à l'EF avec laquelle il a conclu le contrat relatif au sillon, un message de «Prévision de circulation du train», mentionnant la HAPT à l'entreprise ferroviaire impliquée dans ce contrat. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Point de manœuvre |
Gare où l'EF peut modifier la composition du train, mais où elle reste responsable des wagons (pas de changement de responsabilité). |
||||||||||||||||||||||||||||||||||||||||||||||||||
Point de transfert |
Point de transfert de la responsabilité entre deux gestionnaires de l'infrastructure |
||||||||||||||||||||||||||||||||||||||||||||||||||
Point intermédiaire |
Lieu définissant le début ou la fin d'une section du trajet. Il peut s'agir par exemple d'un point de correspondance, de transfert ou de manœuvre. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Poste à poste (point à point, égal à égal, homologue) |
Classe de systèmes et d'applications utilisant des ressources réparties pour réaliser une fonction critique d'une manière décentralisée. Les ressources couvrent la puissance de calcul, les données (mémoire et contenu), la largeur de bande du réseau et la présence (ordinateurs, hommes et autres ressources). La fonction critique peut être un calcul réparti, un partage de données/contenu, la communication et la collaboration ou des services de plate-forme. La décentralisation peut s'appliquer à des algorithmes, à des données et des métadonnées ou à l'ensemble de ces éléments. Cela n'exclut pas le maintien de la centralisation pour certaines parties des systèmes et des applications si la conformité aux exigences demeure assurée. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Prestataire de services |
Transporteur responsable de cette étape spécifique du transport. La partie qui reçoit et gère la réservation. |
||||||||||||||||||||||||||||||||||||||||||||||||||
RARP |
Acronyme de Reverse Address Resolution Protocol (protocole de résolution d'adresse inversé). |
||||||||||||||||||||||||||||||||||||||||||||||||||
Répertoire |
Un répertoire est semblable à une base de données et à un dictionnaire de données. Il inclut en général un environnement avec un système de gestion globale des informations. Il doit aussi inclure non seulement des descriptions des structures de données (c'est-à-dire les entités et les éléments), mais également les métadonnées qui intéressent l'entreprise, des écrans de données, des comptes rendus, des programmes et des systèmes. En général, il comporte un jeu interne d'outils logiciels, un SGBD, un métamodèle, des métadonnées préétablies ainsi qu'un logiciel de chargement et de récupération permettant d'accéder aux données du répertoire centralisé. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Réseau ferroviaire transeuropéen |
Réseau ferroviaire tel qu'il est défini à l'annexe 1 de la directive 2001/16/CE |
||||||||||||||||||||||||||||||||||||||||||||||||||
Réservation |
Réservation d'espace pour expédier des marchandises via un moyen de transport spécifique |
||||||||||||||||||||||||||||||||||||||||||||||||||
RID |
Réglementation concernant le transport ferroviaire international de marchandises dangereuses |
||||||||||||||||||||||||||||||||||||||||||||||||||
RIV |
Règlement régissant l'emploi réciproque de wagons dans le trafic international Règlement régissant l'emploi réciproque des agrès de chargement, des conteneurs et des palettes dans le trafic international. |
||||||||||||||||||||||||||||||||||||||||||||||||||
RPC |
Acronyme de Remote Procedure Call (appel de procédure à distance) Le protocole RPC est défini dans la spécification du protocole d'appel de procédure à distance, version 2 [RFC1831]. |
||||||||||||||||||||||||||||||||||||||||||||||||||
RPV |
Réseau privé virtuel Ce terme était utilisé pour décrire presque tous les types de systèmes de connexion à distance, tels que le réseau téléphonique public et les CVP (circuits virtuels permanents) à relais de trame. Avec l'avènement de l'internet, le RPV est devenu synonyme d'un réseau distant de données fondé sur le protocole IP. En un mot, un RPV est constitué de deux ou plusieurs réseaux privés qui communiquent en toute sécurité sur le réseau public. Il peut y avoir une liaison par RPV entre une machine et un réseau privé (client à serveur) ou entre un réseau local distant et un réseau public (serveur à serveur). Les réseaux privés peuvent se connecter par tunnellisation, tandis qu'un RPV utilise généralement l'internet comme réseau de transport sous-jacent, mais crypte les données échangées entre un client RPV et une passerelle RPV pour s'assurer qu'elles ne pourront pas être lues si elles sont interceptées. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Section de parcours |
Partie du parcours qui se déroule sur un secteur d'infrastructure d'un gestionnaire d'infrastructure ou partie du parcours depuis un point de transfert d'entrée à un point de transfert de sortie de l'infrastructure d'un gestionnaire d'infrastructure. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Sillon |
Représente la capacité d'infrastructure requise pour faire circuler un train donné entre deux lieux donnés sur une période de temps donnée (itinéraire défini dans le temps et dans l'espace). |
||||||||||||||||||||||||||||||||||||||||||||||||||
Sillon |
Itinéraire du train défini dans le temps et l'espace |
||||||||||||||||||||||||||||||||||||||||||||||||||
Sillon/créneau |
Définition de l'itinéraire du train (durée et points de départ et de destination), avec des descriptions détaillées des endroits de passage et d'arrêt, qui peuvent également inclure toute activité du train en cours de route, telles que le changement de personnel de bord, de locomotive ou de composition. |
||||||||||||||||||||||||||||||||||||||||||||||||||
SMTP |
Acronyme de Simple Mail Transfer Protocol (Protocole simplifié de transfert de courrier) |
||||||||||||||||||||||||||||||||||||||||||||||||||
SNMP |
Acronyme de Network Management Protocol (Protocole simplifié de gestion de réseau) |
||||||||||||||||||||||||||||||||||||||||||||||||||
Spécification technique d'interopérabilité |
Spécifications dont chaque sous-système ou partie de sous-système fait l'objet en vue de satisfaire aux exigences essentielles et d'assurer l'interopérabilité du système ferroviaire transeuropéen conventionnel. |
||||||||||||||||||||||||||||||||||||||||||||||||||
SQL |
Acronyme de Structured Query Language (langage de requête structuré) Un langage développé par IBM, puis normalisé par l'ANSI et l'ISO, utilisé pour créer, gérer et récupérer des informations dans des bases de données relationnelles. |
||||||||||||||||||||||||||||||||||||||||||||||||||
STI |
Voir spécification technique d'interopérabilité |
||||||||||||||||||||||||||||||||||||||||||||||||||
Suivi |
Activité qui consiste à surveiller et à enregistrer systématiquement le lieu et l'état courants d'une cargaison, d'un véhicule, d'un équipement, d'un ensemble ou d'un chargement donné. |
||||||||||||||||||||||||||||||||||||||||||||||||||
TCP |
Acronyme de «Transmission Control Protocol» (protocole de contrôle de la transmission) |
||||||||||||||||||||||||||||||||||||||||||||||||||
Terminal intermodal |
Lieu disposant de l'espace, des équipements et de l'environnement opérationnel dans lesquels a lieu le transfert des unités de chargement (conteneurs, caisses mobiles or semi-remorques). |
||||||||||||||||||||||||||||||||||||||||||||||||||
Traçabilité |
Activité dont le but est de trouver et de reconstituer l'historique du transport d'une cargaison, d'un véhicule, d'un équipement, d'un ensemble ou d'un chargement donné. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Train complet |
Forme spécifique de train direct comportant le nombre de wagons strictement nécessaire et circulant entre deux points de transbordement, sans triage intermédiaire. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Train direct |
Train composé des wagons nécessaires et circulant entre deux points de transbordement (origine initiale — destination finale), sans triage intermédiaire. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Train unitaire |
Train de fret expédié avec une seule lettre de voiture et un seul type de marchandises, constitué de wagons uniformes circulant du site d'un expéditeur jusqu'au site d'un destinataire sans triage intermédiaire. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Transbordement |
Opération qui consiste à déplacer les éléments d'un chargement de marchandises ou des charges unitaires d'un véhicule à un autre ou d'un lieu de stockage à un autre. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Transport ferroviaire combiné |
Transport intermodal dans lequel la majeure partie du trajet sur le réseau européen s'effectue par chemin de fer, et dont l'étape initiale et/ou finale effectuée par route est aussi courte que possible. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Transport intermodal |
Mouvement de marchandises en un seul et même véhicule ou unité de chargement, utilisant successivement plusieurs modes de transport sans manutention des marchandises proprement dites lors du passage d'un mode à l'autre. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Tronçon d'itinéraire |
Partie d'un itinéraire |
||||||||||||||||||||||||||||||||||||||||||||||||||
Tunnellisation |
Processus par lequel des paquets IP privés sont intégrés à un paquet IP public. |
||||||||||||||||||||||||||||||||||||||||||||||||||
UDP |
Acronyme de User Datagram Protocol (protocole d'échange de datagramme) Le protocole UDP effectue une simple traversée des NAT (Network Address Translators, traduction des adresses du réseau) (STUN, tunnel série); il s'agit d'un protocole léger qui divulgue la présence et les types de NAT à des applications et met en place un coupe-feu entre ces applications et l'internet public. Il permet également aux applications de déterminer les adresses IP publiques qui leur sont attribuées par le NAT. Le STUN fonctionne avec de nombreux logiciels existants et ne nécessite aucun comportement particulier de leur part. Il permet donc à une large gamme d'applications de fonctionner au sein de l'infrastructure NAT existante. |
||||||||||||||||||||||||||||||||||||||||||||||||||
UIC |
Union internationale des chemins de fer |
||||||||||||||||||||||||||||||||||||||||||||||||||
UITP |
Union internationale des transports publics |
||||||||||||||||||||||||||||||||||||||||||||||||||
UNIFE |
Union des Industries ferroviaire européenne. Cette organisation défend les intérêts des fournisseurs du secteur ferroviaire. Actuellement, une centaine de fournisseurs et de sous-traitants sont représentés directement et environ un millier indirectement, par le biais de leurs organismes nationaux. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Unité intermodale |
Unité de chargement qui peut être transportée par différents modes, comme un conteneur, une caisse mobile, une semi-remorque ou une remorque. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Web |
Service internet qui permet de relier des documents au moyen de liens hypertextes entre serveurs, de sorte qu'un utilisateur peut passer d'un document donné au document correspondant quel que soit l'endroit où il est stocké sur l'internet. |
||||||||||||||||||||||||||||||||||||||||||||||||||
XDR |
Acronyme de «External Data Representation» (représentation de données externes) Le protocole XDR est spécifié dans la norme de représentation de données externes [RFC1832]. XDR est une norme de description et d'encodage des données. Elle est utile pour transférer des données entre différentes architectures informatiques. Elle s'inscrit dans la couche de présentation OSI et sa fonction est globalement analogue à l'ASN (notation syntactique abstraite de l'ISO) définie dans la norme X-409 de l'ISO. La principale différence réside dans le fait que XDR utilise un typage implicite tandis que le X.409 utilise un typage explicite. Par ailleurs, XDR utilise un langage pour décrire des formats des données. Il s'agit d'un langage de description des données uniquement et non d'un langage de programmation. Ce langage permet de décrire de manière concise des formats de données complexes. La solution qui consisterait à utiliser des représentations graphiques (qui sont en soi un langage informel) donne très vite des résultats incompréhensibles dès que les données à représenter deviennent plus complexes. Le langage XDR est à proprement parler semblable au langage C. Des protocoles tels que RPC (Remote Procedure Call, appel de procédure à distance) de l'ONC (architecture réseau ouverte) et NFS (Network File System, système de fichier réseau) utilisent XDR pour décrire le format de leurs données. La norme XDR considère par hypothèse que les octets sont portables. Il faut qu'un périphérique matériel donné code les octets sur les divers supports de façon à ce que d'autres périphériques matériels puissent décoder les octets sans perte de signification. |
||||||||||||||||||||||||||||||||||||||||||||||||||
XML-RPC |
Acronyme de Extensible Markup Language — Remote Procedure Calling (langage de balisage étendu — appel de procédure à distance), ce protocole est largement utilisé sur l'internet. Il définit un format XML pour des messages échangés entre clients et serveurs en HTTP. Un message XML-RPC code soit une procédure à invoquer par le serveur, accompagnée des paramètres à utiliser dans l'appel, soit le résultat d'un appel. Les paramètres et les résultats de ces procédures sont des grandeurs scalaires, des nombres, des chaînes de caractères, des dates, etc. Il peut s'agir également d'enregistrements et de structures de listes complexes. Le document qui décrit ce protocole donne la méthode d'utilisation du protocole BEEP (Blocks Extensible Exchange Protocol) pour échanger des messages codés en format XML-RPC entre clients et serveurs. |
||||||||||||||||||||||||||||||||||||||||||||||||||
XQL |
Acronyme de Extended Structured Query Langage (langage étendu de requête structurée). |
(1) JO L 156 du 28.6.1969, p. 1. Règlement modifié en dernier lieu par le règlement (CEE) no 1893/91 (JO L 169 du 29.6.1991, p. 1).