Agencia Estatal Boletín Oficial del Estado

LA COMISIÓN DE LAS COMUNIDADES EUROPEAS,

Visto el Tratado constitutivo de la Comunidad Europea,

Vista la Directiva 2001/16/CE del Parlamento Europeo y del Consejo, de 19 de marzo de 2001, relativa a la interoperabilidad del sistema ferroviario transeuropeo convencional (1), y, en particular, su artículo 6, apartado 1,

Considerando lo siguiente:

(1) De conformidad con lo dispuesto en el artículo 2, letra c), de la Directiva 2001/16/CE, el sistema ferroviario transeuropeo convencional está subdividido en subsistemas de carácter estructural y funcional. Cada uno de estos subsistemas debe estar regulado por una especificación técnica de interoperabilidad (ETI).

(2) El primer paso para establecer la ETI es que la Asociación Europea para la Interoperabilidad Ferroviaria (AEIF), que fue nombrada organismo común representativo, prepare un proyecto de ETI.

(3) La AEIF ha recibido el mandato de elaborar un proyecto de ETI para las aplicaciones telemáticas del subsistema del transporte de mercancías de conformidad con el artículo 6, apartado 1, de la Directiva 2001/16/CE. Los parámetros fundamentales para este proyecto de ETI fueron aprobados por la Decisión 2004/446/CE de la Comisión, de 29 de abril de 2004, por la que se especifican los parámetros fundamentales sobre ruido, vagones para el transporte de mercancías y aplicaciones telemáticas al servicio del transporte de mercancías para las especificaciones técnicas de interoperabilidad contempladas en la Directiva 2001/16/CE (2).

(4) El proyecto de ETI preparado a partir de los parámetros fundamentales iba acompañado de un informe introductorio con un análisis coste-beneficio según lo dispuesto en el artículo 6, apartado 5, de la Directiva.

(5) Este proyecto ha sido examinado por el Comité creado en virtud del artículo 21 de la Directiva 96/48/CE de 23 de julio de 1996 del Consejo (3) sobre la interoperabilidad del sistema ferroviario transeuropeo de alta velocidad, a la luz del informe introductorio.

(6) Según el artículo 1 de la Directiva 2001/16/CE, las condiciones para lograr la interoperabilidad del sistema ferroviario transeuropeo convencional se refieren al proyecto, construcción, rehabilitación, renovación y explotación de las infraestructuras y el material rodante que contribuyan al funcionamiento del sistema que se ponga en servicio después de la fecha de entrada en vigor de la Directiva. Además, se considera importante la interconexión eficaz de los sistemas de información y comunicación de los distintos administradores de infraestructura y explotadores.

(7) La mayor parte de las actuales aplicaciones telemáticas al servicio del transporte de mercancías se desarrollaron e implantaron con arreglo a los requisitos de los mercados nacionales. Esta situación dificulta la continuidad de los servicios de información a través de las fronteras, factor clave para asegurar la calidad de los servicios ferroviarios internacionales, especialmente en el segmento del transporte internacional de mercancías, en rápido crecimiento.

(8) La ETI sobre aplicaciones telemáticas no debe obligar al uso de soluciones técnicas o tecnologías específicas, excepto cuando sea estrictamente necesario para la interoperabilidad del sistema ferroviario transeuropeo convencional.

_______________________________

(1) DO L 110 de 20.4.2001, p. 1. Directiva modificada por la Directiva 2004/50/CE (DO L 164 de 30.4.2004, p. 114). Directiva corregida en el DO L 220 de 21.6.2004, p. 40.

(2) DO L 155 de 30.4.2004, p. 1. Directiva corregida en el DO L 193 de 1.6.2004, p. 1.

(3) DO L 235 de 17.9.1996, p. 6. Directiva modificada en último lugar por la Directiva 2004/50/CE.

(9) Esta ETI se basa en los mejores conocimientos expertos disponibles en el momento de la elaboración del proyecto correspondiente. La evolución de los requisitos tecnológicos, operativos, sociales o de seguridad puede exigir la modificación o complementación de esta ETI.

Con este fin, se preparará un proceso del tipo Change Control Management para refundir y actualizar los requisitos de la ETI. Este proceso de actualización se situará bajo los auspicios de la Agencia Ferroviaria Europea, establecida en virtud del Reglamento (CE) no 881/2004 del Parlamento Europeo y del Consejo (1), cuando esté operativa, es decir, a más tardar para abril de 2006.

Cuando proceda, se iniciará, con arreglo al artículo 6, apartado 3, de la Directiva 2001/16/CE, un procedimiento de revisión o actualización más profundo y más amplio que implique modificaciones del procedimiento indicado en esta ETI.

(10) En la aplicación de la ETI sobre aplicaciones telemáticas deben tenerse en cuenta criterios específicos relacionados con la compatibilidad técnica y operativa entre las infraestructuras y el material rodante que habrán de ponerse en servicio y la red en la que habrán de integrarse.

Estos requisitos de compatibilidad hacen imprescindible realizar un complejo análisis técnico y económico en cada caso. Este análisis ha de tener en cuenta las interfaces entre los diferentes subsistemas a los que se refiere la Directiva 2001/16/CE, los diferentes tipos de líneas y material rodante mencionados en esta Directiva y los entornos técnicos y operativos de la red existente.

(11) Es esencial que este análisis se lleve a término en un marco coherente de orientaciones y normas de aplicación.

Para ello, se requiere que los organismos representativos del sector ferroviario que operan a nivel europeo establezcan una estrategia europea para la aplicación de la ETI sobre aplicaciones telemáticas. Esta estrategia debe indicar las fases necesarias para pasar de los actuales planteamientos nacionales de la gestión de la información, caracterizados por la fragmentación, a una situación de intercambio de información sin discontinuidades por toda la red ferroviaria de la Unión Europea.

(12) Para asegurar una aplicación eficiente de la ETI, debe elaborarse un Plan Estratégico Europeo de Despliegue.

Los diferentes agentes deben establecer planes graduales, que han de coordinarse a nivel europeo y tener en cuenta los procedimientos y los sistemas de TI actuales de las empresas ferroviarias y los administradores de infraestructuras. Para ello, las empresas ferroviarias y los administradores de infraestructuras tienen que suministrar información técnica funcional acerca de las distintas aplicaciones telemáticas actualmente utilizadas en el transporte de mercancías.

(13) El sistema previsto en la ETI debe basarse en una tecnología informática cuya expectativa de vida útil sea notablemente inferior a la de las actuales instalaciones ferroviarias tradicionales de señalización y telecomunicaciones.

Por eso, exige una estrategia de despliegue proactiva en vez de reactiva, a fin de evitar que el sistema pueda quedar obsoleto antes de que se implanten plenamente sus interconexiones. Además, un despliegue fragmentado por todo el sistema ferroviario europeo causaría importantes costes y gastos generales de explotación al crear incertidumbre respecto a la continuidad del servicio. La elaboración de un plan marco coherente a nivel europeo contribuiría a un desarrollo armonioso de servicios de información sin discontinuidades por todo el sistema ferroviario transeuropeo, de conformidad con la estrategia comunitaria para la red RTE de Transporte.

Un plan de este tipo debe basarse en los planes de aplicación nacional correspondientes e incorporar un conjunto de conocimientos adecuado que pueda servir de base a las distintas partes interesadas para tomar sus decisiones, y, en particular, a la Comisión para asignar ayudas económicas a proyectos ferroviarios. Debe permitirse que la Comisión facilite los medios adecuados para asegurar la coordinación entre las partes que intervengan en la elaboración de este plan europeo.

(14) A fin de evitar cualquier confusión, es necesario dejar sentado que las disposiciones de la Decisión 2004/446/CE que afectan a los parámetros fundamentales del sistema ferroviario transeuropeo convencional no son ya aplicables.

(15) La ETI sobre aplicaciones telemáticas al servicio del transporte de mercancías tiene carácter funcional. En consecuencia, los principales destinatarios de sus disposiciones son los agentes del mercado. Por eso, con miras a la aplicación de las disposiciones de la ETI, es más adecuado un Reglamento dirigido a una gama adecuada de agentes que una Decisión dirigida a los Estados miembros.

(16) Las disposiciones del presente Reglamento se ajustan al dictamen emitido por el Comité establecido con arreglo a la Directiva 96/48/CE.

HA ADOPTADO EL PRESENTE REGLAMENTO:

Artículo 1

La especificación técnica de interoperabilidad («ETI») referente al subsistema «aplicaciones telemáticas al servicio del transporte de mercancías» del sistema ferroviario convencional mencionado en el artículo 6, apartado 1, de la Directiva 2001/16/CE será la que figura en el anexo del presente Reglamento.

La ETI será plenamente aplicable a la infraestructura y el material rodante del sistema ferroviario transeuropeo convencional definido en el anexo I de la Directiva 2001/16/CE.

Artículo 2

Las empresas ferroviarias y los administradores de infraestructuras suministrarán información técnica funcional acerca de las distintas aplicaciones telemáticas actualmente utilizadas en el transporte de mercancías definidas en el capítulo 2 del anexo, en un plazo de seis meses a partir de la entrada en vigor del presente Reglamento.

______________________________

(1) DO L 164 de 30.4.2004, p. 1. Reglamento corregido en el DO L 220 de 21.6.2004, p. 3.

Artículo 3

Los organismos representativos del sector ferroviario que operan a nivel europeo, definidos en el artículo 3, apartado 2, del Reglamento (CE) no 881/2004, establecerán un Plan Estratégico Europeo de Despliegue para la ETI adjunta con arreglo a los criterios especificados en el capítulo 7 del anexo del presente Reglamento.

Remitirán este Plan a los demás Estados miembros y a la Comisión en un plazo de un año a partir de la entrada en vigor del presente Reglamento.

Artículo 4

Las disposiciones de la Decisión 2004/446/CE que se refieren a los parámetros fundamentales del sistema ferroviario transeuropeo convencional dejarán de aplicarse a partir de la fecha de entrada en vigor del presente Reglamento.

Artículo 5

El presente Reglamento entrará en vigor el día siguiente al de su publicación en el Diario Oficial de la Unión Europea.

El presente Reglamento será obligatorio en todos sus elementos y directamente aplicable en cada Estado miembro.

Hecho en Bruselas, el 23 de diciembre de 2005.

Por la Comisión

Jacques BARROT

Vicepresidente

ANEXO

Especificación técnica de interoperabilidad referente a las aplicaciones telemáticas para el subsistema del transporte de mercancías del sistema ferroviario transeuropeo convencional

ÍNDICE:

1. INTRODUCCIÓN . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . 6

1.1. Ámbito de aplicación técnico . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . 6

1.2. Ámbito geográfico . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . 6

1.3. Contenido de la presente ETI . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . 7

2. DEFINICIÓN DEL SUBSISTEMA/ÁMBITO DE APLICACIÓN . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . 7

2.1. Funciones inherentes al ámbito de aplicación de la ETI . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . 7

2.2. Funciones ajenas al ámbito de aplicación de la ETI . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . 7

2.3. Descripción del subsistema . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . 8

2.3.1. Entidades que intervienen . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . 8

2.3.2. Procesos considerados . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . 9

2.3.3. Observaciones generales .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 11

3. REQUISITOS ESENCIALES . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . . 12

3.1. Cumplimiento de los requisitos esenciales . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . 12

3.2. Aspectos de los requisitos esenciales . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . 12

3.3. Aspectos relativos a los requisitos generales . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . 12

3.3.1. Seguridad .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 12

3.3.2. Fiabilidad y disponibilidad . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 13

3.3.3. Salud . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 13

3.3.4. Protección del medio ambiente . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 13

3.3.5. Compatibilidad técnica . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 14

3.4. Aspectos relacionados específicamente con el subsistema «Aplicaciones telemáticas al servicio del transporte de mercancías» . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . 14

3.4.1. Compatibilidad técnica . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 14

3.4.2. Fiabilidad y disponibilidad . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 14

3.4.3. Salud . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 14

3.4.4. Seguridad .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 15

4. CARACTERIZACIÓN DEL SUBSISTEMA . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . . 15

4.1. Introducción . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . 15

4.2. Especificaciones funcionales y técnicas del subsistema . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . 15

4.2.1. Datos de la carta de porte . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 16

4.2.2. Solicitud de surco . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 17

4.2.3. Preparación del tren . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 22

4.2.4. Previsión de circulación del tren . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 25

4.2.5. Información sobre trastornos del servicio . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 27

4.2.6. Ubicación del tren . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 28

4.2.7. Hora prevista de intercambio (ETI)/Hora prevista de llegada (ETA) de un envío . . . . . . .. . . . . . . . .. . . . . . . 30

4.2.8. Movimiento de vagones . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 32

4.2.9. Avisos de intercambio . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 35

4.2.10. Intercambio de información para mejorar la calidad . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 36

4.2.11. Principales datos de referencia . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 38

4.2.12. Varios archivos de referencia y bases de datos . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 40

4.2.13. Transmisión electrónica de documentos . . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 44

4.2.14. Redes y comunicaciones .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 44

4.3. Especificaciones funcionales y técnicas de las interfaces . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . 46

4.3.1. Interfaces con la ETI «Infraestructura» . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 46

4.3.2. Interfaces con la ETI «Control y mando y señalización» . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 46

4.3.3. Interfaces con el subsistema «Material rodante» .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 46

4.3.4. Interfaces con la ETI «Explotación y gestión del tráfico» . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 47

4.4. Normas de funcionamiento . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . 47

4.4.1. Calidad de los datos . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 47

4.4.2. Gestión del depósito de datos central . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 48

4.5. Normas de mantenimiento . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . 48

4.6. Cualificación profesional . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . 49

4.7. Condiciones de salud y seguridad . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . 49

4.8. Registros de infraestructuras y material rodante . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . 49

5. COMPONENTES DE INTEROPERABILIDAD . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . . 49

5.1. Definición . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . 49

5.2. Lista de componentes . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . 50

5.3. Rendimientos y especificaciones de los componentes . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . 50

6. EVALUACIÓN DE CONFORMIDAD E IDONEIDAD DE LOS COMPONENTES Y VERIFICACIÓN DEL SUBSISTEMA . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . . 50

6.1. Componentes de interoperabilidad . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . 50

6.1.1. Procedimientos de evaluación . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 50

6.1.2. Módulo . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 50

6.2. Subsistema «Aplicaciones telemáticas al servicio del transporte de mercancías» . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . 50

7. PUESTA EN PRÁCTICA . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . . 51

7.1. Modalidades de aplicación de la presente ETI . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . 51

7.1.1. Introducción . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 51

7.1.2. Plan estratégico de despliegue europeo (SEDP) .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 51

7.1.3. Modalidades de ejecución . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 52

7.2. Estrategia de migración . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . 53

7.3. Gestión de cambios . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . 56

7.3.1. Introducción . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 56

7.3.2. Determinación de estados básicos . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 57

7.3.3. Revisión de un estado básico . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 58

7.3.4. Despliegue de nuevos estados básicos . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 58

7.3.5. Proceso de gestión de cambios: requisitos . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 58

7.3.6. Plan de administración de configuraciones: requisitos .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 59

7.4. Casos específicos . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . 59

7.4.1. Introducción . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 59

7.4.2. Lista de casos específicos . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . 60

ANEXO A: LISTA DE DOCUMENTOS COMPLEMENTARIOS . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . . 61

ANEXO B: GLOSARIO .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . . 62

TABLAS:

Cuadro 1: Solicitud de surco . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . . 18

Cuadro 2: Cancelación de surco por la EF . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . . 18

Cuadro 3: Cancelación de surco por el IM . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . . 19

Cuadro 4: Acuse de recibo . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . . 19

Cuadro 5: Preparación del tren . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . .. . . . . . . . .. . . . . . . . . 23

Sistema ferroviario transeuropeo convencional Especificación técnica de interoperabilidad Subsistema «Aplicaciones telemáticas al servicio del transporte de mercancías»

1. INTRODUCCIÓN

1.1. Ámbito de aplicación técnico

La presente especificación técnica de interoperabilidad (ETI) se refiere al subsistema «Aplicaciones telemáticas al servicio del transporte de mercancías» mencionado en el anexo II, apartado 1, letra b), de la Directiva 2001/16/CE.

La explotación comercial de trenes, vagones y unidades intermodales en toda la red ferroviaria transeuropea requiere un intercambio eficiente de información entre los distintos administradores de infraestructuras, empresas ferroviarias y otros proveedores de servicios. De esta compatibilidad e intercambio dependen el nivel de prestaciones, la seguridad, la calidad de los servicios y su coste, al igual que, en particular, la interoperabilidad del sistema ferroviario convencional transeuropeo.

La especificación técnica de interoperabilidad también afecta a las condiciones de utilización del transporte ferroviario por los usuarios. En este sentido, se entiende que el término «usuarios» no sólo se refiere a los administradores de infraestructuras o empresas ferroviarias, sino también a todos los demás proveedores de servicios, empresas de vagones, operadores intermodales e incluso clientes.

Finalmente, se han tenido en cuenta las ventajas de la interoperabilidad del sistema ferroviario convencional para poner en práctica las condiciones de una mayor interoperabilidad entre modos de transporte, en particular entre el transporte ferroviario convencional y el transporte ferroviario combinado.

Esta ETI tiene además la finalidad de garantizar que el intercambio eficiente de información se adapte siempre óptimamente a las necesidades que vayan surgiendo, tanto desde el punto de vista de la calidad como de la cantidad, de modo que el proceso de transporte se mantenga tan económicamente viable como sea posible y que el transporte de mercancías por ferrocarril conserve su posición en el mercado frente a la fuerte competencia que debe afrontar.

Todo ello implica la creación o mejora del sistema ferroviario transeuropeo convencional para el transporte convencional y para el transporte intermodal. También se observa la necesidad de modernizar el sector ferroviario del sistema de transporte cuando se consideran los puntos críticos (las interfaces entre los distintos partícipes implicados) del transporte de mercancías por carretera en comparación con los del transporte de mercancías por ferrocarril, en un supuesto simplificado como el que se presenta en el anexo A, índice 5, apartado 1.1.

El objetivo último de la presente ETI es gestionar los envíos en las condiciones de tantas interfaces por medio de un intercambio de información basado en las Directivas 2001/14/CE del Parlamento Europeo y del Consejo (1) y 2001/16/CE.

Esta breve explicación del ámbito de aplicación de la ETI «Aplicaciones telemáticas al servicio del transporte de mercancías» también revela las diferencias con la ETI «Explotación y gestión del tráfico», ambas referentes al transporte ferroviario convencional. La ETI «Explotación y gestión del tráfico» comprende —sobre todo en los aspectos de seguridad— los procedimientos y equipos que permiten asegurar una explotación coherente de los distintos subsistemas estructurales —sobre todo la conducción de los trenes y la planificación y gestión del tráfico—, que constituye la actividad principal de una empresa ferroviaria, de acuerdo con la definición establecida (véase el apartado 2.3: Descripción del subsistema).

La ETI «Aplicaciones telemáticas» comprende las aplicaciones destinadas a los servicios de transporte de mercancías y la gestión de las conexiones con otros modos de transporte, lo que significa que se centra en los servicios de transporte de las empresas ferroviarias, además de la mera explotación de los trenes. Los aspectos de seguridad sólo se tienen en cuenta en la medida en que la existencia de elementos de información —por ejemplo, valores erróneos o no actualizados— pueda afectar a la seguridad de la explotación del tren.

1.2. Ámbito geográfico

El ámbito geográfico de aplicación de la presente ETI es el sistema ferroviario transeuropeo convencional descrito en el anexo I de la Directiva 2001/16/CE. Pero esta ETI también puede aplicarse a toda la red ferroviaria de transporte de mercancías de los Estados miembros de la UE, con la restricción de que los requisitos de la ETI no son obligatorios para el transporte de mercancías con salida o llegada en un país no comunitario.

_____________________________

(1) DO L 75 de 15.3.2001, p. 29. Directiva modificada en último lugar por la Directiva 2004/49/CE (DO L 164 de 30.4.2004, p. 44.

Versión corregida en el DO L 220 de 21.6.2004, p. 16).

1.3. Contenido de la presente ETI

De conformidad con el artículo 5, apartado 3, de la Directiva 2001/16/CE, esta ETI:

a) indica el ámbito de aplicación que cubre el subsistema de Aplicaciones telemáticas al servicio del transporte de mercancías

— Capítulo 2: Definición del subsistema/ámbito de aplicación;

b) precisa los requisitos esenciales aplicables a este subsistema y sus interfaces con otros subsistemas

— Capítulo 3: Requisitos esenciales;

c) define las especificaciones funcionales y técnicas que deben respetar el subsistema y sus interfaces respecto de otros subsistemas

— Capítulo 4: Caracterización del subsistema;

d) determina los componentes de interoperabilidad e interfaces que son objeto de especificaciones europeas, incluidas las normas europeas, que son necesarias para lograr la interoperabilidad del sistema ferroviario transeuropeo convencional

— Capítulo 5: Componentes de interoperabilidad;

e) indica, en cada uno de los casos previstos, los procedimientos de evaluación de la conformidad o de la idoneidad para su uso. Esto incluye, en particular, los módulos definidos en la Decisión 93/465/CEE del Consejo (1) o, en su caso, los procedimientos específicos que deberán utilizarse para evaluar, o bien la conformidad, o bien la idoneidad, de los componentes de interoperabilidad, así como la verificación «CE» de los subsistemas

— Capítulo 6: Evaluación de conformidad e idoneidad de los componentes y verificación del subsistema;

f) indica la estrategia de aplicación de la ETI. En concreto, es necesario especificar las etapas que deben franquearse para pasar de forma gradual de la situación existente a la final, en la cual se habrá generalizado el cumplimiento de la ETI

— Capítulo 7: Puesta en práctica;

g) indica, para el personal afectado, las condiciones de cualificación profesional y de seguridad e higiene en el trabajo requeridas para la explotación y el mantenimiento de este subsistema, así como para la puesta en práctica de la ETI

— Capítulo 4: Caracterización del subsistema.

Además, en virtud del artículo 5, apartado 5, cada ETI podrá prever casos específicos, recogidos en el apartado 7.4: Casos específicos.

Por último, esta ETI también comprende, en el capítulo 4 (Caracterización del subsistema), los requisitos de explotación y mantenimiento específicos para el ámbito de aplicación indicado en los anteriores apartados 1.1 (Ámbito de aplicación técnico) y 1.2 (Ámbito de aplicación geográfico).

2. DEFINICIÓN DEL SUBSISTEMA/ÁMBITO DE APLICACIÓN

2.1. Funciones inherentes al ámbito de aplicación de la ETI El subsistema «Aplicaciones telemáticas al servicio del transporte de mercancías» está definido en el anexo II, apartado 2.5, letra b), de la Directiva 2001/16/CE.

Incluye, en particular:

— aplicaciones destinadas a los servicios de transporte de mercancías, incluidos los sistemas de información (seguimiento en tiempo real de la mercancía y de los trenes),

— sistemas de selección y asignación (entendiéndose por sistemas de asignación la composición de trenes),

— sistemas de reserva (entendiéndose como tal la reserva de franjas o surcos ferroviarios),

— gestión de las correspondencias con otros modos de transporte y expedición de los documentos electrónicos de acompañamiento.

2.2. Funciones ajenas al ámbito de aplicación de la ETI Los sistemas de pago y facturación de los clientes son ajenos al ámbito de aplicación de la presente ETI, al igual que los sistemas de pago y facturación entre distintos proveedores de servicios, como empresas ferroviarias o administradores de infraestructuras. Sin embargo, el diseño subyacente al sistema de intercambio de datos, de acuerdo con el apartado 4.2 (Especificaciones funcionales y técnicas del subsistema), contiene la información necesaria como base para los pagos asociados a los servicios de transporte.

Por otra parte, la planificación a largo plazo de los horarios no corresponde al ámbito de aplicación de la presente ETI «Aplicaciones telemáticas». No obstante, en algunos puntos se hará referencia al resultado de la planificación a largo plazo, en la medida en que exista una relación con el intercambio eficiente de información necesario para la explotación de los trenes.

__________________________

(1) DO L 220 de 30.8.1993, p. 23.

2.3. Descripción del subsistema

2.3.1. Entidades que intervienen

La presente ETI tiene en cuenta a los proveedores de servicios actuales y a los distintos proveedores de servicios que pueden intervenir en el futuro en el transporte de mercancías, dedicados a lo siguiente (esta lista no es exhaustiva):

— vagones,

— locomotoras,

— conductores,

— control de aparatos de vía y operaciones de maniobra en lomo de asno (cambio de rasante),

— venta de surcos o franjas horarios,

— gestión de envíos,

— composición de trenes,

— explotación de trenes,

— vigilancia de trenes,

— control de trenes,

— vigilancia de envíos,

— inspección y reparación de vagones y locomotoras,

— despacho de aduanas,

— terminales intermodales,

— gestión de transportes por carretera.

Algunos proveedores de servicios concretos están definidos expresamente en las Directivas 2001/14/CE y 2001/16/CE. Dado que hay que tener en cuenta ambas Directivas, la presente ETI contempla en particular la siguiente definición (véase el anexo A, índice 6):

«“Administrador de infraestructuras (AI)” cualquier organismo o empresa responsable, en particular, de la instalación y mantenimiento de infraestructuras ferroviarias. Estas funciones podrán incluir asimismo la gestión de los sistemas de control y de seguridad de las infraestructuras. Las funciones del administrador de infraestructuras de una red o parte de una red pueden asignarse a distintos organismos o empresas.».

De acuerdo con esta definición, en la presente ETI se considera al administrador de la infraestructura como el proveedor de los servicios de adjudicación de surcos ferroviarios, de control y vigilancia de los trenes y de información relacionada con los trenes y trazados.

De acuerdo con la Directiva 2001/14/CE, al organismo o empresa a quien el administrador de la infraestructura adjudica una franja o surco ferroviario se le denomina candidato.

«“Candidato” la empresa ferroviaria con licencia o una agrupación internacional de empresas ferroviarias y, en los Estados miembros que prevean esta posibilidad, otras personas físicas o jurídicas interesadas comercialmente o por razones de servicio público en adquirir capacidad de infraestructura, tales como las autoridades públicas con arreglo al Reglamento (CEE) no 1191/69, consignatarios, cargadores y operadores de transporte combinado, para la explotación de un servicio ferroviario en sus territorios respectivos.

“Empresa ferroviaria (EF)” cualquier empresa pública o privada, titular de una licencia con arreglo a la legislación comunitaria aplicable, cuya actividad principal consista en la prestación de servicios de transporte de mercancías o viajeros por ferrocarril, y debiendo ser dicha empresa en todo caso quien aporte la tracción; se incluyen también en la definición las empresas que suministran exclusivamente tracción.».

De acuerdo con esta definición, en la presente ETI se considera que la empresa ferroviaria es la proveedora de los servicios de explotación de trenes.

En relación con la adjudicación de surcos ferroviarios para la circulación de trenes, también hay que tener en cuenta el artículo 13 de la Directiva 2001/14/CE:

«La capacidad de infraestructura será adjudicada por el administrador de infraestructuras y, una vez atribuida a un candidato, éste no podrá transferirla a otra empresa o servicio. Queda prohibida toda transacción relativa a la capacidad de infraestructura; si se llevare a cabo, acarreará la exclusión de la atribución ulterior de capacidad. No se considerará transmisión la utilización de capacidad por parte de una empresa ferroviaria que opere por cuenta de un candidato que no sea empresa ferroviaria.».

En relación con los supuestos de comunicación entre los administradores de infraestructuras y los candidatos en el modo de ejecución de un transporte, sólo hay que tener en cuenta al IM y a la EF y no a todos los tipos de candidatos, que pueden ser pertinentes para el modo de planificación. En el modo de ejecución se da siempre una relación definida entre IM y EF, para la cual se especifica el intercambio de mensajes y el almacenamiento de información en la presente ETI. Esto no influye en la definición de un candidato ni en las consiguientes posibilidades de adjudicación de surcos ferroviarios.

Como ya se ha dicho, el transporte de mercancías requiere la prestación de distintos servicios. Uno de ellos, a modo de ejemplo, es el suministro de vagones. Este servicio puede estar relacionado con un gestor de flota. Si este es uno de los servicios de transporte que ofrece la empresa ferroviaria, entonces ésta actúa además como gestor de flota. Un gestor de flota puede administrar sus propios vagones o los de otro poseedor de material rodante (otro proveedor de servicios para vagones de mercancías). La necesidad de este tipo de proveedor de servicios se tiene en cuenta con independencia de si la entidad jurídica del gestor de flota es la de una empresa ferroviaria o no.

En la presente ETI no se crean nuevas entidades jurídicas ni se obliga a una empresa ferroviaria a contar con proveedores externos para prestar servicios que ella misma ofrezca, pero sí se alude al servicio, si procede, por el nombre del proveedor de servicios correspondiente. Si el servicio es ofrecido por una empresa ferroviaria, ésta actúa como proveedora de dicho servicio.

Desde el punto de vista de la atención a las necesidades del cliente, aparece el servicio consistente en organizar y gestionar la cadena de transporte de acuerdo con el compromiso adquirido con el cliente. Este servicio lo presta la «empresa ferroviaria principal» (EFP). La empresa ferroviaria principal es el único punto de contacto para el cliente. Si interviene más de una empresa ferroviaria en la cadena de transporte, la EFP también se encargará de la coordinación con las demás empresas ferroviarias.

Este servicio también puede ser prestado por un transportista o por cualquier otra entidad.

La actuación de una empresa ferroviaria como EFP puede ser diferente según el tipo de flujo de transporte. En el negocio intermodal, la gestión de la capacidad en trenes en bloque y la preparación de conocimientos de hojas de ruta corresponden a un integrador de servicios intermodales, que puede ser cliente de la EFP.

Sin embargo, lo fundamental es que las empresas ferroviarias y los administradores de infraestructuras, así como todos los demás proveedores de servicios (en el sentido antes definido), deben trabajar conjuntamente, mediante cooperación y/o acceso abierto, así como a través de un intercambio eficiente de información, a fin de prestar servicios integrados al cliente.

2.3.2. Procesos considerados

La presente ETI relativa al sector del transporte ferroviario de mercancías se circunscribe, en virtud de la Directiva 2001/16/CE, a los AI y las EF/EFP con referencia a sus clientes directos.

En la explotación de servicios de mercancías, la actividad de la empresa ferroviaria principal (EFP), en relación con un envío, comienza con la recepción de la carta de porte del cliente y, por ejemplo, para las cargas completas, con el momento de desenganche del vagón. La EFP prepara un plan preliminar de viaje para el trayecto (basándose en su experiencia y/o en el contrato). Si la EFP pretende incorporar el vagón de carga a un tren en modalidad de acceso abierto (la EFP explota el tren durante todo el trayecto), el plan de viaje preliminar es, de por sí, el definitivo. Si la EFP pretende incorporar el vagón de carga a un tren de modo que se requiera la cooperación de otras EF, primero ha de saber a qué EF ha de dirigirse y en qué momento puede producirse el intercambio entre dos EF sucesivas. Entonces la EF prepara las solicitudes de vagón preliminares para cada EF, como partes de la carta de porte completa. Las solicitudes de vagones están especificadas en el apartado 4.2.1 (Datos de la carta de porte).

Las EF destinatarias de las solicitudes comprueban la disponibilidad de recursos para explotar los vagones y la disponibilidad de surcos ferroviarios. Las respuestas de las distintas EF permiten a la EFP afinar el plan de viaje o comenzar de nuevo la consulta —tal vez incluso con otras EF— hasta que el plan de viaje se adapta definitivamente a las necesidades del cliente.

Con carácter general, las EF o EFP deben tener, como mínimo, capacidad para:

— DEFINIR los servicios en términos de precio y tiempos de tránsito, suministro de vagones (si procede), información de vagones o unidades intermodales [ubicación, estado y hora prevista de llegada («ETA») correspondiente al vagón o unidad intermodal], dónde puede realizarse la carga de los envíos en vagones o contenedores vacíos, etc.,

— PRESTAR el servicio definido de manera integrada y fiable, mediante la aplicación de los procesos empresariales normales y sistemas relacionados. Deben existir medios electrónicos de intercambio de información para los administradores de infraestructuras, empresas ferroviarias y otros proveedores de servicios y partes interesadas, como las aduanas,

— VALORAR la calidad del servicio prestado en comparación con el servicio definido, es decir, correspondencia del precio facturado con el ofertado, de los tiempos de tránsito reales con los comprometidos, de los vagones solicitados con los suministrados, o de las horas previstas de llegada con las horas de llegada reales,

— EXPLOTAR de manera productiva, en términos de utilización, la capacidad del tren, de la infraestructura y de la flota, mediante la aplicación de procesos y sistemas empresariales y el intercambio de los datos necesarios para la programación de vagones/unidades intermodales y trenes.

La EF o EFP, en su calidad de candidatas, también deben proporcionar (mediante contratos con los AI) el surco ferroviario necesario y explotar el tren en su parte del trayecto. Para el surco ferroviario pueden utilizar surcos ya reservados (en modo de planificación) o solicitar un surco específico al AI encargado del tramo del trayecto en el que la EF explota el tren. El anexo A, índice 5, apartado 1.2, contiene un ejemplo del supuesto de solicitud de un surco ferroviario.

La propiedad del surco también es importante para la comunicación entre el AI y la EF durante la circulación del tren. La comunicación entre el AI y la empresa ferroviaria, que ha reservado un surco en su infraestructura, debe basarse siempre en el número de tren y surco ferroviario (véase también el anexo A, índice 5, apartado 1.2).

Si una EF se encarga del trayecto completo A-F (en régimen de acceso abierto, sin intervención de otras EF), entonces cada uno de los AI que intervengan se comunicará directamente con esta EF en exclusiva. Este «acceso abierto» por parte de la EF puede hacerse efectivo reservando el surco ferroviario entero, con la empresa de servicio universal, con un sistema de ventanilla única (VU), o por tramos, con cada AI directamente. En la ETI se tienen en cuenta ambos casos, tal como puede verse en el apartado 4.2.2.1: Observaciones preliminares.

El proceso de diálogo entre las empresas ferroviarias y los administradores de infraestructuras para establecer un surco ferroviario para un tren de mercancías se define en el apartado 4.2.2 (Solicitud de surco). Esta función se refiere al artículo 23, apartado 1, de la Directiva 2001/14/CE. El proceso de diálogo no incluye la obtención de la licencia para una empresa ferroviaria que preste servicios de conformidad con la Directiva 2001/13/CE del Parlamento Europeo y del Consejo (1), la certificación en virtud de la Directiva 2001/14/CE ni los derechos de acceso con arreglo a la Directiva 91/440/CEE del Consejo (2).

En el apartado 4.2.3 (Preparación del tren) se define el intercambio de información relativa a la composición del tren y al procedimiento para su salida. El intercambio de datos durante la circulación de un tren en caso de funcionamiento normal se recoge en el apartado 4.2.4 (Previsión de circulación del tren) y los mensajes relativos a las excepciones están definidos en el apartado 4.2.5 (Información sobre trastornos del servicio). El rastreo de información sobre la ubicación del tren se define en el apartado 4.2.6 (Ubicación del tren). Todos estos mensajes se intercambian entre la EF y el AI y están basados en los trenes.

Para un cliente, la información más importante es siempre la hora prevista de llegada (ETA, Estimated Time of Arrival) de su envío. A partir del intercambio de información entre la EFP y el AI (en caso de acceso abierto) se puede calcular una ETA. En el caso del modo de cooperación con distintas EF, es posible determinar la hora prevista de llegada y también la hora prevista de intercambio (ETI, Estimated Time of Interchange) a partir del intercambio de mensajes entre las EF y los AI, y las EF se encargan de comunicarlas a la EFP [apartado 4.2.7:Hora prevista de intercambio (ETI)/Hora prevista de llegada (ETA) de un envío].

Resueltos también a partir del intercambio de información entre el AI y la EF, la EFP conoce, por ejemplo, los siguientes datos:

— cuándo salen o llegan los vagones a un depósito o a ubicaciones definidas (apartado 4.2.8: Movimiento de vagones), o bien

— cuándo se traslada la responsabilidad de los vagones de una empresa ferroviaria a la siguiente de la cadena de transporte (apartado 4.2.9: Avisos de intercambio).

Resueltas no sólo a partir del intercambio de datos entre el AI y la EF, sino también a partir del intercambio de datos entre las EF y la EFP, es posible evaluar distintas estadísticas:

— para planificar —a medio plazo— el proceso productivo con mayor detalle, y

— para realizar —a largo plazo— ejercicios estratégicos de planificación y estudios de capacidad (por ejemplo, análisis de redes, definición de apartaderos y depósitos de clasificación), pero sobre todo

— para mejorar la calidad del servicio de transporte y la productividad (apartado 4.2.10: Intercambio de información para mejorar la calidad).

El manejo de vagones vacíos adquiere especial relevancia cuando se trata de vagones interoperables. En principio, no hay diferencias en el manejo de vagones cargados o vacíos. El transporte de vagones vacíos también se basa en las solicitudes de vagones, en cuyo caso el gestor de la flota a la que pertenecen dichos vagones vacíos debe ser considerado como un cliente.

________________________________

(1) DO L 75 de 15.3.2001, p. 26.

(2) DO L 237 de 24.8.1991, p. 25. Directiva modificada en último lugar por la Directiva 2004/51/CE del Parlamento Europeo y del Consejo (DO L 164 de 30.4.2004, p. 164. Versión corregida en el DO L 220 de 21.6.2004, p. 58).

2.3.3. Observaciones generales

Un sistema de información es tan bueno como los datos que contiene. Por lo tanto, los datos que son decisivos para el transporte de un envío, de un vagón o de un contenedor deben ser exactos y obtenerse de forma económica, es decir, sólo deben entrar en el sistema una vez.

Así pues, las solicitudes y mensajes que recoge la presente ETI evitan la repetida introducción manual de datos mediante el acceso a datos ya almacenados, por ejemplo, los datos de referencia del material rodante. Los requisitos relativos a los datos de referencia del material rodante se definen en el apartado 4.2.11 (Principales datos de referencia). Las bases de datos de referencia de material rodante especificadas deben permitir un fácil acceso a los datos técnicos. El contenido de las bases de datos debe ser accesible y estar basado en una estructura de derechos de acceso en función de los privilegios concedidos a todos los AI, EF y gestores de flota, en particular para la gestión de flotas y el mantenimiento del material rodante. Deben incorporar todos los datos técnicos cruciales para el transporte, como por ejemplo:

— la identificación del material rodante,

— los datos técnicos y de diseño,

— la evaluación de la compatibilidad con la infraestructura,

— la evaluación de las características de carga pertinentes,

— las características relacionadas con los frenos,

— los datos de mantenimiento,

— las características ambientales.

En el negocio del transporte intermodal, hay varios puntos (llamados «centros de tránsito» o Gateways) donde no sólo se conecta un vagón a otro tren, sino que la unidad intermodal puede trasladarse de un vagón a otro. En consecuencia, no basta con trabajar únicamente con un plan de viaje para los vagones, sino que ha de prepararse también un plan de viaje para las unidades intermodales.

En el apartado 4.2.12 (Varios archivos de referencia y bases de datos) se enumeran algunos archivos de referencia y varias bases de datos, entre ellas, la base de datos operativa de vagones y unidades intermodales. Esta base de datos contiene los datos operativos del material rodante, la información de pesos y mercancías peligrosas, la información relacionada con las unidades intermodales y la información de ubicación. El apartado 4.2.13 (Transmisión electrónica de documentos) recoge los requisitos aplicables a la transmisión electrónica de documentos.

La ETI relativa al subsistema de aplicaciones telemáticas al servicio del transporte de mercancías define la información que han de intercambiarse los distintos socios de la cadena de transporte, y permite instalar un proceso estándar obligatorio de intercambio de datos. También presenta la estrategia arquitectónica de tal plataforma de comunicaciones. Esto viene recogido en el apartado 4.2.14 (Redes y comunicaciones), teniendo en cuenta:

— la interfaz con el subsistema «Explotación y gestión del tráfico del sistema ferroviario transeuropeo convencional », mencionada en el artículo 5, apartado 3, de la Directiva 2001/16/CE,

— los requisitos aplicables al contenido de la declaración sobre la red, recogidos en el artículo 3 y el anexo I de la Directiva 2001/14/CE,

— la información disponible sobre el material rodante de los vagones de mercancías y los requisitos relativos al mantenimiento recogidos en la ETI «Material rodante».

No hay transmisión directa de datos del subsistema «Aplicaciones telemáticas al servicio del transporte de mercancías» al tren, al conductor o ninguna parte del subsistema «Control y mando y señalización», y la red de transmisión física es completamente distinta de la red utilizada por el subsistema «Control y mando y señalización ». El sistema ERTMS/ETSC utiliza GSM-R. En esta red abierta, las especificaciones ETCS aclaran que la seguridad se consigue con la correcta gestión de los riesgos de las redes abiertas en el protocolo EURORADIO.

Las interfaces con los subsistemas estructurales «Material rodante» y «Control y mando» sólo vienen dadas a través de las bases de datos de referencia de material rodante (apartado 4.2.11.3: Bases de datos de referencia de material rodante), que están bajo el control de los poseedores del material. Las interfaces con los subsistemas «Infraestructura», «Control y mando» y «Energía» vienen dadas por la definición del surco ferroviario (apartado 4.2.2.3: Mensaje «Datos del surco») que hace el administrador de la infraestructura, donde se especifican valores relativos a la infraestructura pertinentes para el tren, y por la información facilitada por los administradores en relación con las restricciones de la infraestructura (apartado 4.2.11.2: Bases de datos de avisos de restricciones en las infraestructuras).

3. REQUISITOS ESENCIALES

3.1. Cumplimiento de los requisitos esenciales

Con arreglo al artículo 4, apartado 1, de la Directiva 2001/16/CE, el sistema ferroviario transeuropeo convencional y sus subsistemas y componentes de interoperabilidad deberán cumplir los requisitos esenciales definidos en términos generales en el anexo III de la Directiva.

En el ámbito de aplicación de la presente ETI se garantizará el cumplimiento de los requisitos esenciales aplicables al subsistema que se señalan en el capítulo 3 mediante la conformidad con las especificaciones descritas en el capítulo 4: Caracterización del subsistema.

3.2. Aspectos de los requisitos esenciales Los requisitos esenciales abarcan cuestiones de:

— seguridad,

— fiabilidad y disponibilidad,

— salud,

— protección del medio ambiente,

— compatibilidad técnica.

De acuerdo con la Directiva 2001/16/CE, los requisitos esenciales pueden ser aplicables, en general, a todo el sistema ferroviario transeuropeo convencional o, específicamente, a cada subsistema y sus componentes.

3.3. Aspectos relativos a los requisitos generales

La pertinencia de los requisitos generales para el subsistema «Aplicaciones telemáticas al servicio del transporte de mercancías» se determina de la manera siguiente:

3.3.1. Seguridad

De conformidad con el anexo III de la Directiva 2001/16/CE, se aplican al subsistema «Aplicaciones telemáticas al servicio del transporte de mercancías» los siguientes requisitos esenciales relacionados con la seguridad:

— requisito esencial 1.1.1 del anexo III de la Directiva 2001/16/CE:

«La concepción, la construcción o la fabricación, el mantenimiento y la vigilancia de los componentes críticos para la seguridad y, en especial, de los elementos que intervienen en la circulación de los trenes, deben garantizar la seguridad al nivel correspondiente a los objetivos fijados para la red, incluso en situaciones degradadas definidas.».

Este requisito esencial no es pertinente para el subsistema «Aplicaciones telemáticas»,

— requisito esencial 1.1.2 del anexo III de la Directiva 2001/16/CE:

«Los parámetros del contacto rueda-carril deben cumplir los criterios de estabilidad de rodamiento necesarios para garantizar una circulación totalmente segura a la velocidad máxima autorizada.».

Este requisito esencial no es pertinente para el subsistema «Aplicaciones telemáticas»,

— requisito esencial 1.1.3 del anexo III de la Directiva 2001/16/CE:

«Los componentes utilizados deben resistir los esfuerzos normales o excepcionales especificados durante su período de servicio. Aplicando los medios adecuados deben limitarse las repercusiones de sus fallos fortuitos en la seguridad.».

Este requisito esencial no es pertinente para el subsistema «Aplicaciones telemáticas»,

— requisito esencial 1.1.4 del anexo III de la Directiva 2001/16/CE:

«En la concepción de las instalaciones fijas y del material rodante, así como en la elección de materiales, se debe tener en cuenta el objetivo de limitar la producción, propagación y efectos del fuego y el humo en caso de incendio.».

Este requisito esencial no es pertinente para el subsistema «Aplicaciones telemáticas»,

— requisito esencial 1.1.5 del anexo III de la Directiva 2001/16/CE:

«Los dispositivos destinados a ser manipulados por los usuarios deben diseñarse de modo que no pongan en peligro su manejo seguro o la salud y la seguridad de los usuarios en caso de una posible utilización no conforme con los letreros de instrucciones.».

Este requisito esencial no es pertinente para el subsistema «Aplicaciones telemáticas».

3.3.2. Fiabilidad y disponibilidad

«La vigilancia y el mantenimiento de los elementos fijos y móviles que intervienen en la circulación de los trenes deben organizarse, llevarse a cabo y cuantificarse para que su función se siga desempeñando en las condiciones previstas.».

Este requisito esencial se cumple con los apartados siguientes:

Apartado 4.2.11: Principales datos de referencia,

Apartado 4.2.12: Varios archivos de referencia y bases de datos,

Apartado 4.2.14: Redes y comunicaciones.

3.3.3. Salud

— Requisito esencial 1.3.1 del anexo III de la Directiva 2001/16/CE:

«Los materiales que, por su modo de utilización, puedan poner en peligro la salud de las personas que tengan acceso a ellos no deben utilizarse en los trenes ni en las infraestructuras ferroviarias.».

Este requisito esencial no es pertinente para el subsistema «Aplicaciones telemáticas».

— Requisito esencial 1.3.2 del anexo III de la Directiva 2001/16/CE:

«En la elección, puesta en servicio y utilización de estos materiales se debe tener en cuenta el objetivo de limitar la emisión de humos o gases nocivos y peligrosos, especialmente en caso de incendio.».

Este requisito esencial no es pertinente para el subsistema «Aplicaciones telemáticas».

3.3.4. Protección del medio ambiente

— Requisito esencial 1.4.1 del anexo III de la Directiva 2001/16/CE:

«En la concepción del sistema ferroviario transeuropeo convencional deben evaluarse y tenerse en cuenta las repercusiones de su implantación y explotación sobre el medio ambiente, de conformidad con la normativa comunitaria vigente.».

Este requisito esencial no es pertinente para el subsistema «Aplicaciones telemáticas».

— Requisito esencial 1.4.2 del anexo III de la Directiva 2001/16/CE:

«Los materiales utilizados en trenes e infraestructuras deben evitar la emisión de humos o gases nocivos y peligrosos para el medio ambiente, especialmente en caso de incendio.».

Este requisito esencial no es pertinente para el subsistema «Aplicaciones telemáticas».

— Requisito esencial 1.4.3 del anexo III de la Directiva 2001/16/CE:

«El material rodante y los sistemas de alimentación de energía deben diseñarse y fabricarse de modo que sean compatibles desde el punto de vista electromagnético con las instalaciones, los equipos y las redes públicas o privadas con las que pudieran interferir.».

Este requisito esencial no es pertinente para el subsistema «Aplicaciones telemáticas».

— Requisito esencial 1.4.4 del anexo III de la Directiva 2001/16/CE:

«La explotación del sistema ferroviario transeuropeo convencional debe respetar los niveles reglamentarios en materia de molestias sonoras.».

Este requisito esencial no es pertinente para el subsistema «Aplicaciones telemáticas».

— Requisito esencial 1.4.5 del anexo III de la Directiva 2001/16/CE:

«La explotación del sistema ferroviario transeuropeo convencional no debe provocar en el suelo un nivel de vibraciones inadmisible para las actividades y el medio por el que discurra, en las proximidades de la infraestructura y en estado normal de mantenimiento.».

Este requisito esencial no es pertinente para el subsistema «Aplicaciones telemáticas».

3.3.5. Compatibilidad técnica

— Requisito esencial 1.5 del anexo III de la Directiva 2001/16/CE:

«Las características técnicas de las infraestructuras y de las instalaciones fijas deben ser compatibles entre sí y con las de los trenes que vayan a circular por el sistema ferroviario transeuropeo convencional. En caso de que, en algunas partes de la red, resulte difícil ajustarse a dichas características, podrían aplicarse soluciones temporales que garanticen la compatibilidad futura.».

Este requisito esencial no es pertinente para el subsistema «Aplicaciones telemáticas».

3.4. Aspectos relacionados específicamente con el subsistema «Aplicaciones telemáticas al servicio del transporte de mercancías»

3.4.1. Compatibilidad técnica

— Requisito esencial 2.7.1 del anexo III de la Directiva 2001/16/CE:

«Los requisitos esenciales en los ámbitos de las aplicaciones telemáticas que garantizan un mínimo de calidad de servicio a los viajeros y a los clientes del sector de transporte de mercancías se refieren, en especial, a la compatibilidad técnica.

Para estas aplicaciones telemáticas se garantizará:

— que las bases de datos, los programas informáticos y los protocolos de comunicación de datos se desarrollen de forma que permitan el máximo de intercambio de datos tanto entre aplicaciones diferentes como entre operadores distintos, con exclusión de los datos comerciales confidenciales,

— un acceso fácil a la información por parte de los usuarios.».

Este requisito esencial se cumple especialmente con los apartados siguientes:

Apartado 4.2.11: Principales datos de referencia,

Apartado 4.2.12: Varios archivos de referencia y bases de datos,

Apartado 4.2.14: Redes y comunicaciones.

3.4.2. Fiabilidad y disponibilidad

— Requisito esencial 2.7.2 del anexo III de la Directiva 2001/16/CE:

«Los modos de utilización, gestión, actualización y mantenimiento de dichas bases de datos, programas informáticos y protocolos de comunicaciones de datos garantizarán la eficacia de dichos sistemas y la calidad del servicio.».

Este requisito esencial se cumple especialmente con los apartados siguientes:

Apartado 4.2.11: Principales datos de referencia,

Apartado 4.2.12: Varios archivos de referencia y bases de datos,

Apartado 4.2.14: Redes y comunicaciones.

Sin embargo, este requisito esencial, especialmente el método de utilización que garantice la eficacia de estas aplicaciones telemáticas y la calidad del servicio, es el fundamento de toda la ETI y no se limita únicamente a los apartados antes mencionados.

3.4.3. Salud

— Requisito esencial 2.7.3 del anexo III de la Directiva 2001/16/CE:

«Las interfaces de dichos sistemas con los usuarios deberán respetar las normas mínimas en cuanto a ergonomía y protección de la salud.».

En esta ETI no se especifica ningún requisito adicional a las normas nacionales y europeas vigentes en relación con normas mínimas sobre ergonomía y protección de la salud de las interfaces entre estas aplicaciones telemáticas y los usuarios.

3.4.4. Seguridad

— Requisito esencial 2.7.4 del anexo III de la Directiva 2001/16/CE:

«Deberán garantizarse niveles de integridad y fiabilidad suficientes para el almacenamiento o la transmisión de información relacionada con la seguridad.».

Este requisito se cumple con los apartados siguientes:

Apartado 4.2.11: Principales datos de referencia,

Apartado 4.2.12: Varios archivos de referencia y bases de datos,

Apartado 4.2.14: Redes y comunicaciones.

4. CARACTERIZACIÓN DEL SUBSISTEMA

4.1. Introducción

El sistema ferroviario transeuropeo convencional (al que se aplica la Directiva 2001/16/CE y del que forma parte el subsistema «Aplicaciones telemáticas») es un sistema integrado cuya coherencia debe verificarse. Esta coherencia debe verificarse, en particular, con respecto a las especificaciones del subsistema y sus interfaces con el sistema en el que está integrado, así como a las normas de explotación y mantenimiento.

Teniendo en cuenta todos los requisitos esenciales aplicables, el subsistema «Aplicaciones telemáticas al servicio del transporte de mercancías» se caracteriza por lo siguiente:

4.2. Especificaciones funcionales y técnicas del subsistema

Con arreglo a los requisitos esenciales señalados en el capítulo 3 (Requisitos esenciales), las especificaciones funcionales y técnicas del subsistema son las siguientes:

— datos de la carta de porte,

— solicitud de surco,

— preparación del tren,

— previsión de circulación del tren,

— información sobre trastornos del servicio,

— ubicación del tren,

— ETI/ETA de vagones y unidades intermodales,

— movimiento de vagones,

— avisos de intercambio,

— intercambio de información para mejorar la calidad,

— principales datos de referencia,

— varios archivos de referencia y bases de datos,

— transmisión electrónica de documentos,

— redes y comunicaciones.

Las especificaciones detalladas siguen a continuación. Para conocer más detalles y los formatos de los mensajes, véase el anexo A, índice 1.

Observaciones generales sobre la estructura de los mensajes

Los mensajes están estructurados en dos conjuntos de datos:

— datos de control: véase la explicación más adelante,

— datos de información: información de la solicitud.

Los datos de control presentan los siguientes elementos:

— estado: el estado de un mensaje puede ser:

«Nuevo mensaje», si se trata de un mensaje nuevo,

«Modificación», si se trata de la modificación de un mensaje anterior,

«Borrado», si debe eliminarse el anterior mensaje enviado,

— referencia del mensaje con:

Tipo de mensaje: por ejemplo, «solicitud de surco» o «consulta sobre circulación del tren», Fecha y hora: fecha y hora efectiva de envío del mensaje, Número de mensaje: número generado por el remitente del mensaje,

— referencia asociada, sólo si el mensaje es la respuesta a un mensaje anteriormente recibido (idéntico a la «Referencia del mensaje» del mensaje recibido) con:

Tipo asociado: tipo del mensaje recibido,

Fecha y hora asociadas: fecha y hora del mensaje recibido,

Número asociado: número del mensaje recibido,

— remitente del mensaje,

— destinatario del mensaje.

En los apartados siguientes se contempla principalmente el estado «Nuevo mensaje». En el apartado 4.2.2: Solicitud de surco también se hace referencia al estado «borrado» en relación con el mensaje «Solicitud de surco».

4.2.1. Datos de la carta de porte

4.2.1.1. Carta de porte del cliente

El cliente deberá enviar la carta de porte a la empresa ferroviaria principal (EFP). Ésta deberá contener toda la información necesaria para transportar el envío del remitente al consignatario. La EFP aportará información adicional y suplementaria a estos datos. Estos datos, incluidos los adicionales, aparecen relacionados en el cuadro del anexo A, índice 3, indicándose en la fila «Datos en carta de porte» si son obligatorios u opcionales y si deben ser facilitados por el remitente o de forma suplementaria por la EFP.

En caso de acceso abierto, la EFP que contrate con el cliente contará con toda la información cuando reciba el suplemento de los datos disponibles. No hace falta intercambiar mensajes con otras EF. Estos datos constituyen, además, la base para una solicitud de surco ferroviario para uso inminente, si ésta es necesaria para ejecutar la carta de porte.

Los mensajes siguientes corresponden al caso de acceso no libre. El contenido de estos mensajes también puede servir de base a las solicitudes de uso inminente de surco, si son necesarias para ejecutar la carta de porte.

4.2.1.2. Solicitudes de vagones

La solicitud de vagón constituye básicamente una parte de la información de la carta de porte. Debe remitirse a las empresas ferroviarias que intervienen en la cadena de transporte, ya que puede convertirse en la base para una solicitud de surco específico (apartado 4.2.2: Solicitud de surco). La solicitud de vagón ha de aportar la información necesaria para que una empresa ferroviaria lleve a cabo el transporte bajo su responsabilidad hasta el momento de la transferencia a la siguiente empresa ferroviaria. Por consiguiente, su contenido dependerá de la función que realice la empresa, que puede ser: empresa ferroviaria de origen (EFO), de tránsito (EFT) o de entrega (EFE):

— solicitud de vagón para la empresa ferroviaria de origen (EFO),

— solicitud de vagón para la empresa ferroviaria de tránsito (EFT),

— solicitud de vagón para la empresa ferroviaria de entrega (EFE).

Los datos que contienen las solicitudes de vagones se reflejan con detalle en el anexo A, índice 3, de acuerdo con las distintas funciones que puede desempeñar la empresa ferroviaria, marcados según sean obligatorios u opcionales. Los formatos detallados de estos mensajes se definen en el anexo A, índice 1.

Contenido principal de las solicitudes de vagones:

— información sobre el remitente y el consignatario,

— información de ruta,

— identificación del envío,

— información sobre el vagón,

— información sobre lugares y fechas.

Algunos datos de la nota de envío deben ser accesibles a todos los partícipes de la cadena de transporte, incluidos los clientes (por ejemplo, el administrador de la infraestructura, el poseedor del material rodante, etc.).

En particular se trata de los datos siguientes, por vagón:

— peso de la carga (peso bruto),

— número CN/HS,

— información de mercancías peligrosas,

— unidad de transporte.

4.2.2. Solicitud de surco

4.2.2.1. Obse rva cione s pre liminar es Planificación a largo plazo

El surco ferroviario define los datos solicitados, aceptados y reales que deberán almacenarse en relación con el surco que corresponde a un tren y las características del tren para cada segmento de dicho surco. A continuación se describe la información que debe estar a disposición del administrador de la infraestructura. Véase una descripción más pormenorizada en el anexo A, índice 4.

Esta información deberá actualizarse siempre que se produzca un cambio.

Principales datos del surco:

— identificación del surco ferroviario (número de surco). Un surco podría ser un uso planificado de la capacidad a lo largo de un tramo de ruta, o el encaminamiento del tren por una línea determinada de una ruta.

Esto dependerá de los procesos que aplique el administrador de la infraestructura,

— punto de salida del surco, que es el lugar donde comienza el surco, junto con la fecha y hora de salida del tren que circula por dicho surco,

— destino del surco ferroviario, que es el lugar donde termina el surco, junto con la fecha y hora a la que está prevista la llegada del tren a dicho destino,

— descripción del tramo del trayecto, que define los datos facilitados por el administrador de la infraestructura para cada tramo de recorrido aceptado: desde el principio hasta la primera parada intermedia, las paradas intermedias posteriores y desde la última parada intermedia hasta el final de trayecto aceptado. Esta descripción puede comprender:

— paradas intermedias u otros puntos designados a lo largo del surco propuesto, con la fecha y hora de llegada, salida o paso por estos puntos intermedios, así como un código de actividad, que define la actividad que se realizará en ese punto intermedio del trayecto,

— identificación del AI responsable de la gestión del tráfico en el tramo actual del trayecto e identificación del AI responsable de la gestión del tráfico en el tramo siguiente,

— descripción de los equipos (sistema de mando y control, sistema de radio, etc.) que deberá llevar el tren; debe ser compatible con la infraestructura para habilitar la tracción, el control y las comunicaciones del tren con el control del administrador de la infraestructura,

— datos relativos al tren para el tramo del trayecto: peso máximo, longitud máxima, velocidad máxima, peso máximo por eje, fuerza mínima de freno, peso máximo por metro, información relativa a gálibos excepcionales e identificadores de mercancías peligrosas no admitidas,

— número de surco,

— tiempo de circulación adicional en el tramo de recorrido para prever operaciones de encarrilamiento, problemas de surco, etc.

Contrato de surco de ejecución: antes de que un tren circule debe actualizarse el tramo del trayecto y completarse con valores reales. El modo de ejecución es independiente del modo de planificación.

Solicitud de uso inminente de surco

Debido a las excepciones que pueden darse durante la circulación del tren o a las exigencias de transporte imprevistas, las empresas ferroviarias deben tener la posibilidad de obtener un surco ad hoc en la red.

En el primer caso, deberán ponerse en marcha medidas inmediatas, a través de las cuales se conozca la composición real del tren basada en la lista de composición del tren.

En el segundo caso, la empresa ferroviaria deberá facilitar al administrador de la infraestructura todos los datos necesarios sobre los tiempos y lugares por los que debe circular el tren, así como sobre sus características físicas, en la medida en que interactúen con la infraestructura. Por lo general, esta información se facilitará en el suplemento de la carta de porte de cada solicitud de vagón.

El acuerdo de uso inminente de surco se basa en un diálogo entre las EF y los AI. En este diálogo participan todas las EF y los AI que intervienen en el movimiento del tren por el surco deseado, pero quizá con una contribución distinta al proceso de localización del surco. De acuerdo con el artículo 13 de la Directiva 2001/14/CE, cabe distinguir principalmente dos supuestos diferentes para el transporte de mercancías sobre las infraestructuras de varios AI (véase también el anexo A, índice 5, apartado 1.3):

— supuesto A: la empresa ferroviaria se pone en contacto con todos los AI que intervienen, bien directamente (caso A), bien a través de la empresa de servicio universal (caso B), a fin de organizar los surcos para todo el trayecto. En este caso, la empresa ferroviaria deberá explotar el tren durante todo el trayecto de conformidad con lo dispuesto en el artículo 13 de la Directiva 2001/14/CE,

— supuesto B: cada empresa ferroviaria que intervenga en el transporte se pondrá en contacto con los administradores de la infraestructura local, bien directamente, bien a través de la empresa de servicio universal, a fin de solicitar un surco para el tramo del trayecto en el que dicha empresa explota el tren.

Observación: como ya se ha indicado en el capítulo 2 (Definición del subsistema/ámbito de aplicación), en el modo de ejecución el AI siempre se comunica con la EF que ha reservado el surco. Por lo tanto, la «propiedad del surco» es importante para el intercambio de mensajes durante la explotación del tren.

En ambos supuestos, el procedimiento de reserva de surco para uso inminente se corresponde con el diálogo entre las EF y los AI, tal como se describe a continuación.

El cuadro siguiente presenta los mensajes utilizados en el diálogo de solicitud de un surco ferroviario:

Cuadro 1

Solicitud de surco

TABLA OMITIDA EN PÁGINA 18

Este diálogo concluye con el envío por la EF del mensaje de Confirmación de surco o con la supresión de la solicitud de surco (mensaje de Solicitud de surco en estado «Borrado», véase el apartado 4.2: Especificaciones funcionales y técnicas del subsistema, Observaciones generales sobre la estructura de los mensajes). El mensaje «Rechazo de datos del surco» que envía la EF debe ir acompañado siempre de un nuevo mensaje «Datos del surco». Si el AI no puede atender la solicitud de surco con una nueva propuesta en el mensaje «Datos del surco», deberá enviar el mensaje sobre los datos del surco con la indicación «No hay alternativas disponibles», que pone fin al diálogo con el AI.

Tanto si el surco se ha reservado en el marco de la planificación a largo plazo como mediante una solicitud para uso inminente, la EF debe tener siempre la posibilidad de cancelar un surco reservado. Para cancelar un surco reservado deberá utilizarse el siguiente mensaje:

Cuadro 2

Cancelación de surco por la EF

TABLA OMITIDA EN PÁGINA 18

En virtud del acuerdo de surco, la empresa ferroviaria puede suponer que un surco reservado estará de hecho disponible. Por lo tanto, si por algún motivo el surco reservado deja de estar disponible, el administrador debe informar a la empresa tan pronto como conozca esta circunstancia. A modo de ejemplo, este caso puede darse si se produce una interrupción en el surco ferroviario. Esto puede ocurrir en cualquier momento desde que se contrata el surco hasta que sale el tren. El administrador está obligado a enviar una propuesta alternativa junto con la indicación «Surco no disponible». Si esto no es posible, el administrador deberá enviar la propuesta lo antes posible. Con el mensaje «surco no disponible» comienza un diálogo para alcanzar un nuevo acuerdo de surco, iniciado por el AI.

Mensajes utilizados en el diálogo de cancelación de un surco reservado por el AI:

Cuadro 3

Cancelación de surco por el AI

TABLA OMITIDA EN PÁGINA 19

En general, si el destinatario de una solicitud o consulta no puede responder en tiempo real, debe informar al remitente del mensaje (por ejemplo, si no es posible enviar el mensaje «Datos del surco» de forma inmediata en respuesta a la «Solicitud de surco»). Para ello debe utilizarse el siguiente mensaje:

Cuadro 4

Acuse de recibo

TABLA OMITIDA EN PÁGINA 19

Estos mensajes se describen señalando los principales datos en los siguientes apartados. Los formatos detallados están definidos en el anexo A, índice 1. La secuencia lógica de estos mensajes está reflejada en los diagramas del anexo A, índice 5, apartados 2.1 a 2.3.

4.2.2.2. Mensaje «Solicitud de surco»

Esta es la solicitud que envía la empresa ferroviaria al administrador de la infraestructura para obtener un surco.

Esta solicitud debe contener:

— punto de salida del surco: lugar donde comienza el surco propuesto,

— fecha y hora de salida del surco: fecha y hora solicitadas para el surco,

— punto de destino del surco: destino del tren para el surco solicitado,

— fecha y hora de llegada al destino del surco: fecha y hora a la que está prevista la llegada del tren propuesto a su destino,

— tramo de trayecto solicitado:

— paradas intermedias u otros puntos designados del surco propuesto, con fecha y hora a la que está prevista la llegada del tren propuesto a un punto intermedio y la fecha y hora a la que está prevista la salida del tren desde un punto intermedio. Una entrada en blanco indica que no hay parada en ese punto,

— equipos disponibles en el tren: tipo de tracción, sistema de mando y control, incluido el equipo de radio de a bordo,

— peso del tren,

— longitud del tren,

— sistema de frenado que se utilizará y rendimiento de frenado,

— velocidad máxima del tren,

— peso máximo por eje del tren,

— peso máximo por metro,

— información relativa a gálibos excepcionales,

— números ONU/RID relativos a mercancías peligrosas,

— definiciones de actividades que deberán realizarse en los puntos intermedios del trayecto,

— EF responsable: identificación de la empresa ferroviaria responsable del tren en el tramo actual del trayecto,

— AI responsable: identificación del administrador de la infraestructura responsable del tren en el tramo actual del trayecto,

— próximo AI responsable: identificación del administrador de la infraestructura responsable del tren en el tramo siguiente del trayecto (en su caso).

Como fuente de información auxiliar para la formulación de la solicitud de surco, la empresa ferroviaria puede consultar la declaración de red pertinente, a fin de comprobar si los datos del tren en cuestión son conformes con la infraestructura. También habrá que tener en cuenta datos como la información sobre mercancías peligrosas.

Los poseedores de los vagones deben facilitar a la empresa ferroviaria el acceso a los datos técnicos de estos últimos.

Las propias empresas ferroviarias deben asegurarse el acceso a los archivos de referencia, por ejemplo al correspondiente a las mercancías peligrosas, si es necesario.

4.2.2.3. Mensaje «Datos del surco»

Este mensaje es la respuesta de un administrador de infraestructuras al mensaje «Solicitud de surco» enviado por una empresa ferroviaria. En el caso de que el AI no pueda atender la solicitud de surco, deberá enviar este mensaje con la indicación «No hay alternativas disponibles». En caso contrario, deberá contestar a la solicitud de la EF enviando un número de surco que contenga los mismos datos que figuren en la solicitud, si bien algunos valores pueden ser modificados.

El administrador de la infraestructura deberá enviar los siguientes datos con la alternativa propuesta:

— nuevo número de surco,

— punto de salida del surco: lugar donde comienza el surco propuesto,

— fecha y hora de salida del surco: fecha y hora propuestas para el surco,

— punto de destino del surco: destino del tren para el surco propuesto,

— fecha y hora de llegada al destino del surco: fecha y hora a la que está prevista la llegada del tren a su destino,

— tramo de trayecto modificado:

— paradas intermedias u otros puntos designados del surco propuesto, con fecha y hora a la que está prevista la llegada del tren propuesto a un punto intermedio y la fecha y hora a la que está prevista la salida del tren desde un punto intermedio. Una entrada en blanco indica que no hay parada en ese punto,

— equipos necesarios en el tren: tipo de tracción, sistema de mando y control, incluido el equipo de radio de a bordo,

— peso del tren,

— longitud del tren,

— sistema de frenado que se utilizará y rendimiento de frenado,

— velocidad máxima del tren,

— peso máximo por eje del tren,

— peso máximo por metro,

— información relativa a gálibos excepcionales,

— números ONU/RID relativos a mercancías peligrosas,

— definiciones de actividades que deberán realizarse en los puntos intermedios del trayecto,

— EF responsable: identificación de la empresa ferroviaria responsable del tren en el tramo actual del trayecto,

— AI responsable: identificación del administrador de la infraestructura responsable del tren en el tramo actual del trayecto,

— próximo AI responsable: identificación del administrador de la infraestructura responsable del tren en el tramo siguiente del trayecto (en su caso).

4.2.2.4. Mensaje «Confirmación de surco»

Este mensaje deberá ser enviado por la empresa ferroviaria al administrador de la infraestructura para aceptar el surco propuesto según la solicitud original de la empresa. Con este mensaje, el surco queda reservado. El contenido principal del mensaje es el siguiente:

— número de surco que identifica el surco ferroviario,

— punto de salida del surco: lugar de salida del tren,

— fecha y hora de salida del surco: fecha y hora solicitadas para el surco,

— punto de destino del surco: destino del tren para el surco solicitado,

— fecha y hora de llegada al destino del surco: fecha y hora a la que está prevista la llegada del tren propuesto a su destino,

— indicación de que la EF acepta el surco propuesto.

4.2.2.5. Mensaje «Rechazo de datos del surco»

La empresa ferroviaria enviará este mensaje al administrador de la infraestructura en el caso de que no acepte el surco propuesto por éste en el mensaje «Datos del surco». Datos principales:

— número de surco que identifica el surco ferroviario,

— indicación de que no se aceptan los datos del surco.

A título complementario pueden enviarse los siguientes datos:

— punto de salida del surco: lugar de salida del tren,

— fecha y hora de salida del surco: fecha y hora solicitadas para el surco,

— punto de destino del surco: destino del tren para el surco solicitado,

— fecha y hora de llegada al destino del surco: fecha y hora a la que está prevista la llegada del tren propuesto a su destino.

4.2.2.6. Mensaje «Cancelación de surco»

Con este mensaje, la empresa ferroviaria notifica la cancelación de un surco previamente reservado. A fin de identificar el surco de forma inequívoca, debe enviarse el número de surco junto con el indicador de cancelación (corresponde al tipo de mensaje). Esto se aplica a la reserva de surcos tanto en modalidad de planificación como de solicitud de uso inminente:

— número de surco que identifica el surco ferroviario,

— número del tren (si el AI ya lo conoce),

— indicación de que se cancela el surco ferroviario reservado.

A título complementario pueden enviarse los siguientes datos:

— punto de salida del surco: lugar de salida del tren,

— fecha y hora de salida del surco: fecha y hora solicitadas para el surco,

— punto de destino del surco: destino del tren para el surco solicitado,

— fecha y hora de llegada al destino del surco: fecha y hora a la que está prevista la llegada del tren propuesto a su destino.

4.2.2.7. Mensaje «Surco no disponible»

Si el administrador de la infraestructura tiene conocimiento de que un surco ferroviario no está disponible, deberá comunicarlo lo antes posible a la empresa ferroviaria. El mensaje «Surco no disponible» puede enviarse en cualquier momento entre la contratación del surco y la salida del tren. A modo de ejemplo, este caso puede darse si se produce una interrupción en el surco ferroviario. El contenido principal de este mensaje es el siguiente:

— número del surco no disponible,

— número del tren previsto para el surco cancelado (si el AI ya lo conoce),

— punto de salida del surco, con la fecha y hora para la cual estaba reservada,

— punto de destino del surco, con la fecha y hora a la que está prevista la llegada del tren a su destino,

— indicación «Surco no disponible»,

— indicación de la causa.

El administrador de la infraestructura deberá enviar una propuesta alternativa, junto con este mensaje o lo antes posible, sin necesidad de que la empresa ferroviaria realice una nueva solicitud. Para ello se utiliza el mensaje «Datos del surco» asociado a este mensaje «Surco no disponible».

4.2.2.8. Mensaje «Acuse de recibo»

Esta información será enviada por el destinatario de un mensaje a su remitente si no es posible dar la respuesta solicitada en el intervalo de tiempo definido en el apartado 4.4. (Normas de funcionamiento). Este mensaje debe tener un identificador de referencia (indicaciones en Mensaje asociado, véase el apartado 4.2: Especificaciones funcionales y técnicas del subsistema, Observaciones generales sobre la estructura de los mensajes) y la indicación (Nivel de aplicación):

— acuse de recibo: indica que el destinatario ha recibido el mensaje y actuará en consecuencia.

4.2.3. Preparación del tren

4.2.3.1. Observaciones generales

En este apartado se especifican los mensajes que deben intercambiarse durante la fase de preparación del tren hasta su partida. Los mensajes se describen más abajo, en el cuadro 5.

Para la preparación del tren, la empresa ferroviaria ha de tener acceso a los avisos de restricción de la infraestructura, a los datos técnicos de los vagones (apartado 4.2.11.3: Bases de datos de referencia de material rodante), al fichero de referencia de mercancías peligrosas y al estado en curso de la información actualizada sobre los vagones (apartado 4.2.12.2: Otras bases de datos: Base de datos operativa de vagones y unidades intermodales). Esta información se refiere a todos los vagones que componen el tren. Al final, la EF deberá enviar la composición del tren a las EF siguientes. También deberá enviar este mensaje al administrador o administradores de infraestructuras a los que haya reservado un tramo de surco ferroviario, cuando así lo especifique la ETI «Explotación y gestión del tráfico» del sistema ferroviario convencional o cuando lo establezcan los contratos suscritos entre la EF y el administrador o administradores de infraestructuras.

Si la composición del tren se modifica en un lugar, se deberá enviar una vez más este mensaje a todas las partes implicadas con la información actualizada por parte de la empresa ferroviaria responsable.

En cada punto donde cambie la responsabilidad de la EF responsable —por ejemplo, punto de origen e intercambio—, el AI y la EF tendrán la obligación de establecer el diálogo del procedimiento de salida «Tren listo: información de circulación del tren».

En el diálogo del procedimiento de salida se utilizan los siguientes mensajes:

Cuadro 5

Preparación del tren

TABLA OMITIDA EN PÁGINA 23

Estos mensajes se describen en los siguientes apartados, indicándose los principales datos que contienen. Los formatos detallados están definidos en el anexo A, índice 1. La secuencia lógica está reflejada en el anexo A, índice 5, capítulo 3.

Observación: durante la preparación del tren también puede aparecer un mensaje «Surco no disponible», ya que este mensaje puede enviarse en cualquier momento desde que se contrata el surco hasta que sale el tren. El procedimiento correspondiente está descrito en el apartado 4.2.2 (Solicitud de surco).

4.2.3.2. Mensaje «Composición del tren»

Este mensaje deberá ser enviado por una EF a la siguiente EF, y en él se definirá la composición del tren. Este mensaje también deberá ser enviado por la EF al administrador o administradores de infraestructuras cuando así lo requiera la ETI «Explotación y gestión del tráfico» del sistema ferroviario convencional o cuando lo establezcan los contratos suscritos entre AI y EF. Siempre que se produzca un cambio de composición durante el trayecto de un tren, la EF responsable deberá enviar este mensaje de actualización a todas las partes implicadas.

La información que deberá transmitirse y permanecer accesible es la siguiente:

— número de tren y número de surco que identifica el surco ferroviario,

— punto de salida del surco, con la fecha y hora para la cual se había solicitado,

— punto de destino del surco, con la fecha y hora a la que está prevista la llegada del tren propuesto a su destino,

— identificación de la locomotora o locomotoras y posición de éstas en el tren,

— longitud, peso y velocidad máxima del tren,

— composición del tren con la secuencia de identificadores de vehículos,

— sistema de mando y control, incluido el tipo de equipo de radio,

— información relativa a gálibos excepcionales,

— números ONU/RID de las mercancías peligrosas,

— indicación de si se transporta ganado y personas (distintas del personal del tren),

— sistema de frenos que se utilizará,

— datos de los vagones.

A la recepción de la composición del tren, el AI podrá contrastar sus datos con los del surco contratado, si el contrato entre AI y EF lo prevé expresamente. En este caso, el AI debe poder acceder con facilidad a la información sobre posibles restricciones en la infraestructura correspondiente, a los datos técnicos de los vagones (apartado 4.2.11.3: Bases de datos de referencia de material rodante), al fichero de referencia de mercancías peligrosas y a la información actualizada sobre los vagones (apartado 4.2.12.2: Otras bases de datos, Base de datos operativa de vagones y unidades intermodales). Esta información se refiere a todos los vagones que componen el tren. En ese caso, además, el AI, que gestiona sus surcos y mantiene actualizada la información sobre éstos, deberá añadir los datos de la composición del tren a los datos del surco y del tren mencionados en el apartado 4.2.2.1 (Solicitud de surco, Observaciones preliminares).

4.2.3.3. Mensaje «Tr en ac eptado»

En función del contrato entre el AI y la EF y de lo que disponga la normativa, el administrador de la infraestructura también podrá comunicar a la empresa ferroviaria si la composición del tren es aceptable para el surco reservado. Dicha comunicación se lleva a cabo mediante este mensaje.

El contenido principal de este mensaje es el siguiente:

— número del tren y del surco,

— punto de salida del surco, con la fecha y hora para la cual se había solicitado,

— punto de destino del surco, con la fecha y hora a la que está prevista la llegada del tren propuesto a su destino,

— indicación de que el AI ha aceptado que la composición del tren es adecuada para el surco acordado.

4.2.3.4. Mensaje «Tren inadecuado»

Si el tren no es adecuado para el surco previamente acordado, el administrador de la infraestructura podrá comunicarlo a la empresa ferroviaria mediante este mensaje. En este caso, la empresa deberá volver a comprobar la composición del tren. El contenido principal de este mensaje es el siguiente:

— número del tren y del surco,

— punto de salida del surco, con la fecha y hora para la cual se había solicitado,

— punto de destino del surco, con la fecha y hora a la que está prevista la llegada del tren propuesto a su destino,

— indicación «Inadecuado», que indica que el tren no es adecuado para la franca adjudicada y, por lo tanto, no puede circular,

— indicación de la causa.

4.2.3.5. Mensaje «Tren listo»

Este mensaje será enviado por la empresa ferroviaria al administrador de la infraestructura para indicar que el tren está listo para acceder a la red. El contenido principal de este mensaje es el siguiente:

— número del tren y del surco,

— punto de salida del surco, con la fecha y hora para la cual se había solicitado,

— punto de destino del surco, con la fecha y hora a la que está prevista la llegada del tren propuesto a su destino,

— indicación «Tren listo», que indica que el tren ha sido preparado y está listo para circular,

— identificación de la persona del centro de control encargada de las comunicaciones tren-tierra,

— si el acuerdo contractual entre la EF y el AI no requiere el intercambio de los mensajes «Posición del tren/ Tren en punto de salida», deberá definirse en este mensaje la «Fecha/hora de salida del tren», que informa al administrador de la fecha y hora prevista para que se presente el tren en la red. En el caso de que se requiera el intercambio de los mensajes «Posición del tren/Tren en punto de salida», no será necesario transmitir estos datos.

4.2.3.6. Mensaje «Posición del tren»

El administrador de la infraestructura podrá enviar este mensaje a la empresa ferroviaria para definir exactamente el momento y lugar en que el tren debe presentarse en la red, como respuesta al mensaje de tren listo. El envío de este mensaje dependerá del contrato entre la empresa ferroviaria y el administrador de la infraestructura. En el caso de que sea necesaria esta transmisión, el contenido principal del mensaje será el siguiente:

— número del tren y del surco,

— punto de salida del surco, con la fecha y hora para la cual se había solicitado,

— punto de destino del surco, con la fecha y hora a la que está prevista la llegada del tren propuesto a su destino,

— identificación de la vía, que indica a la empresa ferroviaria en qué vía de la red debe presentarse el tren,

— fecha/hora de salida del tren, que indica a la empresa ferroviaria en qué fecha y hora exactas debe presentarse el tren en la red,

— identificador del contacto de control.

4.2.3.7. Mensaje «Tren en punto de salida»

La empresa ferroviaria podrá enviar este mensaje al administrador de la infraestructura tras recibir del mismo el mensaje «posición del tren», a fin de indicar que el tren ha iniciado el trayecto. Este mensaje deberá contener el identificador de referencia y la indicación:

— tren en punto de salida: fecha y hora a la que el tren ha iniciado efectivamente su trayecto.

4.2.3.8. Información sobre el tren en circulación

Tan pronto el tren esté presente en la infraestructura de un administrador, lo que significa que el tren ha abandonado la estación de salida, el AI enviará este mensaje a la EF que haya reservado el surco. Este mensaje está descrito en el apartado 4.2.4 (Previsión de circulación del tren).

4.2.4. Previsión de circulación del tren

4.2.4.1. Observaciones generales

En este apartado se especifican los mensajes que deben intercambiarse durante la circulación normal de un tren sin interrupciones.

Los mensajes pertinentes son:

Previsión de circulación del tren

Información sobre el tren en circulación

Este intercambio de información entre las EF y los AI siempre tendrá lugar entre el AI responsable y la EF que haya reservado el surco por el que circule el tren. En caso de acceso abierto, lo que significa que los surcos de todo el trayecto han sido reservados por una sola empresa ferroviaria (y que, además, esta empresa explota el tren durante todo el trayecto), todos los mensajes se enviarán a esta empresa. Se procederá de igual manera si los surcos del trayecto han sido reservados por una empresa ferroviaria a través de la empresa de servicio universal (VU).

A continuación se distinguen varios supuestos, teniendo en cuenta las distintas relaciones de comunicación existentes entre empresas ferroviarias y administradores de la infraestructura, de acuerdo con los supuestos de reserva de surcos ferroviarios señalados en el apartado 4.2.2.1 (Solicitud de surco, Observaciones preliminares, supuestos A y B):

— Aproximación de un tren a un punto de transferencia entre el AI no 1 y el AI no 2 adyacente.

Se supone que el punto de transferencia no es ni un punto de intercambio (sólo supuesto B) ni un punto de manipulación. Así, el punto de transferencia es un punto situado en los surcos reservados por una EF, la cual ya ha enviado la composición del tren al AI no 2, al tiempo que envía este mensaje al AI no 1.

El AI no 1, una vez efectuada la salida desde el punto de salida (1), deberá enviar un mensaje de previsión de circulación del tren al AI no 2, con indicación de la hora prevista de transferencia (ETH, Estimated Time of Handover). Este mensaje se envía simultáneamente a la empresa ferroviaria.

_____________________________

(1) Se entiende por punto de salida el punto inicial del surco, que puede ser el punto de salida del tren al principio del viaje o un punto de intercambio. El punto de transferencia es el punto final del surco.

Cuando el tren abandona la infraestructura del AI no 1 en el punto de transferencia, este AI envía un mensaje de información sobre el tren en circulación con la hora efectiva de transferencia en este punto a la EF que ha contratado su surco.

Cuando el tren llega a la infraestructura del AI no 2 en el punto de transferencia, éste AI envía un mensaje de información sobre el tren en circulación con la hora efectiva de transferencia desde este punto a la EF que ha contratado su surco.

— Aproximación de un tren a un punto de intercambio entre la EF 1 y la EF 2 (sólo supuesto B).

En el contrato de surco, los puntos de intercambio deben definirse siempre como puntos de notificación. (Las horas previstas de llegada del tren a los puntos de notificación serán generadas por los AI especificados en sus contratos con las EF.)

En relación con este punto, el AI responsable enviará, una vez el tren abandone el punto de notificación anterior, un mensaje de previsión de circulación del tren con la hora prevista de llegada del tren (ETA-T, Train Estimated Time of Arrival) a este punto de intercambio a la EF que haya contratado el surco (por ejemplo, EF 1). La EF 1 transmitirá este mensaje a la EF siguiente (por ejemplo, EF 2) que ha de hacerse cargo del tren. Además, este mensaje se enviará a la empresa ferroviaria principal (EFP) encargada del transporte, si existe y se ha definido en el contrato de cooperación entre ambas empresas ferroviarias.

Si el punto de intercambio es también un punto de transferencia entre el AI no 1 y el AI no 2, el AI no 1 enviará el mensaje de previsión de circulación del tren al AI no 2, una vez efectuada su salida desde el punto de salida o desde el punto de intercambio anterior, con indicación de la hora prevista de transferencia (ETH). Este mensaje también se envía a la EF que ha contratado el surco, por ejemplo la EF 1. Para la EF, la ETH es igual a la ETA-T en el punto de intercambio. La EF 1 transmitirá este mensaje a su EF 2 adyacente y a la EFP encargada del transporte, si existe y está definida en el contrato de cooperación entre ambas empresas ferroviarias.

Cuando el tren llegue a un punto de intercambio, el AI deberá enviar un mensaje de información sobre el tren en circulación a la EF que haya contratado su surco, por ejemplo la EF 1, con indicación de la hora efectiva de llegada a dicho punto.

Antes de que el tren abandone el punto de intercambio, la EF 2 enviará un nuevo mensaje de composición del tren al AI que haya adjudicado el surco y seguirá el procedimiento de salida definido en el apartado 4.2.3 (Preparación del tren).

— Aproximación de un tren a un punto de manipulación de una empresa ferroviaria (supuesto A).

Los puntos de manipulación deberán definirse siempre en el contrato de surco como puntos de notificación.

En relación con este punto, el AI responsable enviará un mensaje de previsión de circulación del tren que sólo indicará una ETA-T si así se ha especificado en el contrato entre el AI y la EF.

Pero si el punto de manipulación es también un punto de transferencia entre, por ejemplo, el AI no 1 y el AI no 2, el AI no 1 enviará el mensaje de previsión de circulación del tren a la AI no 2, una vez efectuada su salida desde el punto de salida o desde el punto de intercambio anterior, con indicación de la hora prevista de transferencia (ETH). Este mensaje también se envía a la EF. Para la EF, la ETH es igual a la ETA-T en el punto de manipulación.

Cuando llegue el tren al punto de manipulación, el AI enviará a la EF un mensaje de información sobre el tren en circulación con indicación de la hora efectiva de llegada a este punto.

Antes de que el tren abandone el punto de manipulación, la EF y el AI seguirán el procedimiento de salida definido en el apartado 4.2.3 (Preparación del tren).

— Llegada del tren a destino.

Cuando llegue el tren a su destino, el AI responsable enviará un mensaje de información sobre el tren en circulación, con indicación de la hora efectiva de llegada, a la EF contratante del surco.

Observación: en el contrato de surco también pueden definirse otras ubicaciones que requieran el envío del mensaje de previsión de circulación del tren con la ETA-T y del mensaje de información sobre el tren en circulación con la hora efectiva. En relación con estos puntos, el AI responsable enviará estos mensajes tal como se especifique en el contrato. La evaluación y el tratamiento posteriores de las ETH y ETA-T transmitidas se describe en los apartados 4.2.7 [Hora prevista de intercambio (ETI)/Hora prevista de llegada (ETA) de un envío] a 4.2.9 (Avisos de intercambio).

En los apartados siguientes, los mensajes «Previsión de circulación del tren» e «Información sobre el tren en circulación » se describen señalando únicamente su contenido principal. Los formatos detallados se definen en el anexo A, índice 1. La secuencia lógica de este intercambio de mensajes en relación con los distintos supuestos de comunicación se describe en el anexo A, índice 5, capítulo 4, con la observación de que, con respecto de la relación de comunicación entre la EF y los AI sobre la circulación del tren, los dos supuestos de solicitud de surco A (caso A) y A (caso B) (apartado 4.2.2.1: Solicitud de surco, Observaciones preliminares,) son idénticos, porque en ambos casos los AI sólo conocen una EF, por ejemplo la EF 1, que explota todo el surco y que es además responsable de la nueva composición del tren en los puntos de manipulación.

4.2.4.2. Mensaje «Previsión de circulación del tren»

Este mensaje debe ser enviado por el AI para los puntos de transferencia e intercambio y para el destino del tren, tal como se indica en el apartado 4.2.4.1 (Observaciones generales, Previsión de circulación del tren).

Además, este mensaje debe ser enviado por el AI a la EF en relación con otros puntos de notificación, de acuerdo con los contratos entre ambas entidades (por ejemplo, en relación con los puntos de manipulación).

Datos principales:

— número de surco y número del tren,

— fecha y hora programada de salida en la ubicación del AI (u hora programada de transferencia al siguiente AI),

— identificación del punto de notificación,

— fecha y hora previstas en el punto de notificación.

4.2.4.3. Mensaje «Información sobre el tren en circulación»

Este mensaje deberá enviarse en los siguientes momentos:

— salida desde el punto de salida y llegada a destino,

— llegada y salida de los puntos de transferencia e intercambio y en los puntos de notificación acordados en el contrato (por ejemplo, puntos de manipulación).

Datos principales:

— número de surco y número del tren,

— fecha y hora programadas de salida en la ubicación del AI,

— identificación del punto de notificación más reciente,

— hora efectiva en el punto de notificación,

— estado del punto de notificación del tren (llegada, salida, paso, no especificado, salida de origen o llegada a destino),

— vía de llegada a la ubicación,

— vía de salida de la ubicación,

— minutos de desviación Delta de la hora programada reservada,

— programación actual si ha habido numerosas reprogramaciones,

— por cada desviación de la «Hora programada reservada» en ese punto de notificación:

— código de razón (tal vez múltiple),

— tiempo de desviación correspondiente a este código de razón (pueden indicarse múltiples motivos por punto de notificación),

— es posible añadir texto libre sobre la desviación.

4.2.5. Información sobre trastornos del servicio

4.2.5.1. Observaciones generales

Si la empresa ferroviaria tiene conocimiento, durante la circulación del tren, de un trastorno del servicio que le sea imputable, lo comunicará inmediatamente al administrador de la infraestructura (no mediante un mensaje informático, sino, por ejemplo, verbalmente por parte del conductor). Si es necesario, la EF actualizará la base de datos operativa de vagones y unidades intermodales. Si es necesario, el AI actualizará los datos de la infraestructura en la base de datos de avisos de restricciones en infraestructuras o en la base de datos del surco o del tren, respectivamente.

Si el retraso es superior a x minutos (este valor deberá figurar en el contrato entre la EF y el AI), el AI enviará a la EF un mensaje de previsión de circulación del tren asociado al siguiente punto de notificación.

Si el tren es cancelado, el AI enviará un mensaje de interrupción de la circulación del tren, tal como se especifica a continuación.

En casos excepcionales en que la EF o el AI no puedan hacer circular el tren a la hora prevista, deberá negociarse un nuevo surco con arreglo al apartado 4.2.2 (Solicitud de surco).

4.2.5.2. Mensaje «Interrupción de la circulación del tren»

Si el tren es cancelado, el AI enviará este mensaje al AI adyacente y a la EF que ha contratado el surco.

Este mensaje deberá contener los siguientes datos principales:

— número de surco y del tren,

— identificación de la ubicación,

— fecha y hora programadas de salida desde esta ubicación,

— razones de la interrupción,

— descripción de la interrupción.

4.2.6. Ubicación del tren

4.2.6.1. Prefacio

En este apartado se especifica la posibilidad de realizar un rastreo para obtener información sobre la ubicación del tren. La EF puede consultar al AI sobre sus trenes en cualquier momento. La EF puede hacer una consulta sobre:

— la circulación del tren (última ubicación registrada, retrasos, razones de los retrasos),

— la puntualidad de un tren (retrasos, razones de los retrasos, ubicaciones de los retrasos),

— todos los identificadores de un tren determinado,

— previsión del tren en una ubicación especificada,

— todas las previsiones de circulación del tren correspondientes a una ubicación especificada.

El acceso a esta información deberá ser independiente de la comunicación entre la EF y el AI durante la circulación del tren, lo que implica que la EF debe contar con una dirección única (1) de acceso a esta información. Esta información se basa principalmente en el intercambio de mensajes antes mencionado.

4.2.6.2. Consulta sobre los mensajes de circulación del tren

Objeto: la empresa ferroviaria pregunta por la última situación registrada (ubicación, retrasos y motivos de los retrasos) de un tren determinado en la infraestructura de un determinado administrador.

Consulta: datos principales:

— número del tren en circulación,

— identificador del AI,

— fecha y hora programadas de salida en la ubicación del AI.

Respuesta: datos de información:

— punto de notificación más reciente,

— hora efectiva en el punto de notificación,

— estado del punto de notificación del tren (llegada, salida, paso, no especificado, salida de origen o llegada a destino),

— vía de llegada a la ubicación,

— vía de salida de la ubicación,

— hora programada reservada,

— retraso Delta con respecto a la hora programada reservada,

— hora reprogramada (comparada con la programación actual en caso de reprogramaciones múltiples),

— por cada retraso en ese punto de notificación:

— código de razón y tiempo de retraso correspondiente.

_________________________________

(1) Esto significa que el acceso a esta información debe ser independiente del AI que haya almacenado la información o parte de la misma.

4.2.6.3. Consulta sobre los mensajes de retraso/puntualidad del tren

Objeto: la empresa ferroviaria solicita información sobre todos los retrasos sufridos por un tren determinado con un determinado administrador de la infraestructura.

Consulta: datos principales:

— número del tren en circulación,

— identificador del AI,

— fecha y hora programadas de salida en la ubicación del AI.

Respuesta: datos de información (la misma información que en el caso de la «Consulta sobre circulación del tren», no sólo sobre el punto más reciente sino sobre cada punto de notificación del tren en la infraestructura del administrador especificado):

— por cada punto de notificación:

— punto de notificación más reciente,

— hora efectiva en el punto de notificación,

— estado del punto de notificación del tren (llegada, salida, paso, no especificado, salida de origen o llegada a destino),

— vía de llegada a la ubicación,

— vía de salida de la ubicación,

— hora programada reservada,

— retraso Delta con respecto a la hora programada reservada,

— hora reprogramada (comparada con la programación actual en caso de reprogramaciones múltiples),

— por cada retraso en ese punto de notificación:

— código de razón y tiempo de retraso correspondiente.

4.2.6.4. Consulta sobre los mensajes «Identificador del tren»

Objeto: la empresa ferroviaria pregunta por el identificador actual del tren y los identificadores anteriores.

En esta consulta puede utilizarse cualquiera de los identificadores correspondientes a un tren determinado.

Consulta: datos principales:

— número conocido del tren en circulación,

— identificador del AI,

— fecha y hora programadas de salida en la ubicación del AI.

Respuesta: datos de información:

— identificador actual del tren:

— número del tren en circulación,

— fecha y hora programadas de salida en la ubicación del AI,

— con respecto a los demás identificadores:

— número del tren en circulación,

— fecha y hora programadas de salida en la ubicación del AI.

4.2.6.5. Consulta al AI sobre los mensajes «Previsión del tren»

Objeto: la empresa ferroviaria pregunta la hora prevista para un tren determinado en un determinado punto de notificación o bien, a falta de un punto de notificación, pregunta por la hora prevista en el punto de transferencia del administrador de la infraestructura.

Consulta: datos principales:

— número del tren en circulación,

— fecha y hora programadas de salida en la ubicación del AI,

— identificación del punto de notificación (con respecto al cual se solicita la previsión. Este dato es opcional y, si no se indica expresamente, la respuesta se refiere al punto de notificación final de ese AI en relación con este tren.)

Respuesta: datos de información:

— código del AI,

— identificación del punto de notificación,

— fecha y hora previstas en el punto de notificación.

4.2.6.6. Consulta al AI sobre los mensajes «Trenes en el lugar de notificación»

Objeto: la empresa ferroviaria solicita información sobre todos los trenes que se encuentren en un determinado punto de notificación de la infraestructura de un administrador determinado.

Consulta: datos principales:

— código del AI,

— identificación del punto de notificación (para el cual se solicita la previsión. Este dato es opcional y, si no se indica expresamente, la respuesta se refiere al punto de notificación final de ese AI en relación con este tren.)

Respuesta: datos de información:

— por cada uno de los trenes del consultante:

— número del tren en circulación,

— fecha y hora programada de salida en la ubicación del AI (u hora programada de transferencia),

— código del AI,

— identificación del punto de notificación,

— fecha y hora previstas en el punto de notificación.

4.2.7. Hora prevista de intercambio (ETI)/Hora prevista de llegada (ETA) de un envío

4.2.7.1. Observación preliminar

En los apartados 4.2.2 (Solicitud de surco) a 4.2.6 (Ubicación del tren) se ha descrito principalmente la comunicación entre la empresa ferroviaria y el administrador de la infraestructura. Dado que la tarea de este último es la supervisión y el control de los trenes, el elemento clave para esta comunicación es el número del tren. La parte de información sobre los vagones que incorpora el mensaje de composición del tren es importante para cotejar la composición del tren con el contrato de surco entre AI y EF y en los casos excepcionales.

Este intercambio de información no comprende la vigilancia individual de vagones o unidades intermodales. Esto se hace por parte de la EF/EFP sobre la base de los mensajes relacionados con el tren y se describe en los apartados 4.2.7 [Hora prevista de intercambio (ETI)/Hora prevista de llegada (ETA) de un envío] a 4.2.9 (Avisos de intercambio).

El intercambio y la actualización de información relacionada con vagones o unidades intermodales se sustenta esencialmente en el almacenamiento de «planes de viaje» y «movimientos de vagones» (apartado 4.2.12.2: Otras bases de datos).

Como ya se ha dicho en el apartado 2.3.2 (Procesos considerados), para un cliente la información más importante es siempre la hora prevista de llegada (ETA) de su envío. La ETA y la ETI del vagón son además la información básica de las comunicaciones entre la EFP y la EF. Esta información es el principal instrumento de que dispone la EFP para supervisar el transporte físico de un envío y para verificarlo con arreglo al compromiso contraído con el cliente.

Las horas previstas en los mensajes relativos al tren están relacionadas con la llegada de un tren a un punto determinado, que puede ser un punto de transferencia, un punto de intercambio, el destino del tren u otro punto de notificación. Todas éstas son horas previstas de llegada del tren (ETA-T). La ETA-T puede tener distintos significados para los diversos vagones o unidades intermodales de que consta el tren. Por ejemplo, la ETA-T de un punto de intercambio puede ser la hora prevista de intercambio (ETI) de algunos vagones o unidades intermodales. Para otros vagones que permanecen en el tren y cuyo transporte ha de continuar la misma empresa ferroviaria, es posible que la ETA-T no tenga relevancia alguna. Corresponde a la empresa ferroviaria que recibe la información sobre la ETA-T identificar y procesar esa información, almacenarla como movimiento de vagones en la base de datos operativa de vagones y unidades intermodales y comunicarla a la EFP, si el tren no circula en modo de acceso abierto. Esto se examina en los apartados siguientes.

4.2.7.2. Cá lculo de la ETI y la ETA

El cálculo de la ETI y la ETA se basa en la información facilitada por el AI responsable, quien envía, dentro del mensaje «Previsión de circulación del tren», la hora prevista de llegada del tren (ETA-T) a los puntos de notificación definidos (y, en cualquier caso, a los puntos de transferencia, puntos de intercambio o puntos de llegada, incluidas las terminales intermodales) en el surco ferroviario acordado, por ejemplo el punto de transferencia de un AI al siguiente (en este caso, la ETA-T es igual a la ETH).

Para los puntos de intercambio u otros puntos de notificación definidos en el surco ferroviario acordado, la EF debe calcular la hora prevista de intercambio (ETI) de los vagones y unidades intermodales para la siguiente EF de la cadena de transporte.

Como una EF puede tener vagones con distintos trayectos y pertenecientes a distintas EFP dentro del mismo tren, el punto de intercambio para calcular la ETI puede no ser el mismo para todos los vagones. Esto se explica en los dos ejemplos simplificados que se describen a continuación (el anexo A, índice 5, apartado 1.4 incluye una representación gráfica de estos supuestos, y el anexo A, índice 5, capítulo 5 presenta el diagrama secuencial basado en el ejemplo 1 relativo al punto de intercambio C).

Ejemplo 1: la EF 1 tiene los vagones no 1 y 2 de la EFP 1 y los vagones no 3, 4 y 5 de la EFP 2 en el mismo tren. En el punto de intercambio C, la EF 2 se encarga de continuar el transporte de los vagones 1 y 2 y la EF3 de los vagones 3, 4 y 5. En este caso, la EF 1 debe calcular la ETI de los vagones 1 y 2 en relación con el punto de intercambio C y enviar los valores a la EFP 1. La EF 1 también debe calcular la ETI de los vagones 3, 4 y 5 en relación con el mismo punto de intercambio C y enviar estos valores a la EFP 2.

Ejemplo 2: la EF 1 tiene los vagones no 1 y 2 de la EFP 1 y los vagones no 3, 4 y 5 de la EFP 2 en el mismo tren. En el punto de intercambio C, la EF 3 se encarga de continuar el transporte de los vagones 3, 4 y 5, mientras que los vagones 1 y 2 permanecen en el tren de la EF 1 hasta el punto de intercambio E, donde la responsabilidad de estos vagones pasará a la EF 2. En este caso, la EF 1 sólo deberá calcular la ETI de los vagones 3, 4 y 5 en relación con el punto de intercambio C y enviar los valores a la EFP 2. El punto de intercambio C no es pertinente para los vagones 1 y 2. El siguiente punto de intercambio pertinente para estos vagones es el E y en relación con este punto, la EF 1 debe calcular la ETI y enviar estos valores a la EFP 1.

La EF siguiente, basándose en la ETI indicada por la EF anterior, calcula por su parte la ETI del vagón relativa al siguiente punto de intercambio. Estos pasos son efectuados por cada EF sucesiva. Cuando la última EF (por ejemplo, EF n) de la cadena de transporte de un vagón recibe de la EF anterior (por ejemplo, EF n-1) la ETI relativa al intercambio del vagón entre la EF n-1 y la EF n, la última EF (EF n) debe calcular la hora prevista de llegada de los vagones a su destino final. De este modo se tiene en cuenta la colocación de los vagones en el orden establecido y en consonancia con el compromiso adquirido por la EFP con su cliente. Esta es la ETA del vagón y debe ser enviada a la EFP. Debe almacenarse electrónicamente, junto con el movimiento del vagón.

La EFP debe otorgar al cliente acceso a sus datos pertinentes, de acuerdo con las condiciones contractuales.

Observación: sobre las unidades intermodales: por lo que respecta a las unidades intermodales de un vagón, las ETI del vagón son también las ETI de las unidades intermodales. Por lo que respecta a las ETA relativas a las unidades intermodales, hay que señalar que la EF no está en condiciones de calcular esta ETA más allá de la parte de transporte ferroviario. Por lo tanto, la EF sólo puede facilitar ETI relacionadas con la terminal intermodal.

La EFP será responsable de comparar la ETA con el compromiso adquirido con el cliente.

Las desviaciones de la ETA respecto del compromiso adquirido con el cliente deberán gestionarse de conformidad con el contrato correspondiente y podrán dar lugar a un procedimiento de gestión de alertas por parte de la EFP. Para la transmisión de información sobre el resultado de este proceso se ha previsto el mensaje «Alerta».

Para realizar el proceso de gestión de alertas, la EFP debe poder investigar las desviaciones sufridas por cada vagón. Para ello realiza una consulta, que se especifica a continuación, junto con la respuesta de la EF.

4.2.7.3. Mensaje ETI/ETA de l vagón

Objeto: enviar una ETI o una ETI actualizada de una EF a la siguiente de la cadena de transporte. La última EF de la cadena de transporte de los vagones envía la ETA o ETA actualizada a la EFP.

Datos principales:

— identificación de la EF que ha generado la ETI o ETA,

— estación de salida o estación de intercambio anterior (ETI u hora de salida de la estación de origen),

— número del tren que sale de la estación de salida o estación de intercambio anterior (a partir de la ETI u hora de salida de la estación de origen),

— fecha y hora efectivas de salida del tren,

— estación de llegada o siguiente estación de intercambio (fin ETI/ETA),

— número del tren que llega a la estación final de la ETI/ETA (estación de llegada o siguiente estación de intercambio),

— fecha y hora de llegada del vagón (ETI o ETA).

4.2.7.4. Mensaje «Alerta »

Objeto: tras la comparación entre la ETA y el compromiso con el cliente, la EFP podrá enviar un mensaje de «Alerta» a las EF implicadas.

Datos principales:

— número de vagón,

— compromiso con el cliente: fecha y hora de llegada,

— ETA efectiva: fecha y hora.

Observación: en caso de acceso abierto, el cálculo de la ETI y la ETA será un proceso interno de la EF. En este caso, la EF será la propia EFP.

4.2.7.5. Consulta sobre mensajes de desviación de vagones.

Objeto: la EFP pregunta por las desviaciones de un vagón específico.

Consulta: Datos principales

— número de vagón,

— identificador de la EFP.

Respuesta: datos de información:

— por cada punto de notificación:

— lugar de notificación,

— situación del punto de notificación del vagón (salida, llegada al depósito, salida del depósito, llegada al punto de intercambio, llegada al depósito de destino),

— EF responsable en el lugar de notificación y de acuerdo con la situación del punto de notificación del vagón,

— hora reprogramada (comparada con la programación actual en caso de reprogramaciones múltiples),

— ETI, si el punto de notificación es un punto de intercambio,

— hora efectiva en el punto de notificación,

— por cada desviación en ese punto de notificación:

— código de razón y tiempo de retraso correspondiente.

4.2.8. Movimiento de vagones

4.2.8.1. Observaciones preliminares

En relación con el aviso de movimiento de un vagón, los datos siguientes deberán estar almacenados y accesibles por medios electrónicos. Asimismo, deberán enviarse a las partes autorizadas dentro de los mensajes contemplados en el contrato. Los formatos detallados se definen en el anexo A, índice 1:

— aviso de liberación del vagón,

— aviso de salida del vagón,

— llegada al depósito de vagones,

— salida del depósito de vagones,

— mensaje de excepción del vagón,

— aviso de llegada del vagón,

— aviso de entrega del vagón en destino,

— confirmación de entrega del vagón en destino,

— aviso de intercambio del vagón, se describe por separado en el apartado 4.2.9: Avisos de intercambio.

4.2.8.2. Mensaje «Aviso de liberación del vagón»

Objeto: EFP a EF: la empresa ferroviaria principal no es necesariamente la primera empresa ferroviaria de la cadena de transporte. En este caso, la EFP debe informar a la EF responsable de que el vagón está listo para ser remolcado a los apartaderos del cliente (lugar de salida, de acuerdo con el compromiso de la EFP) a la hora especificada de liberación (fecha y hora de salida).

Estos eventos deben almacenarse en la base de datos operativa de vagones y unidades intermodales.

Datos principales:

— número de vagón,

— lugar, fecha y hora de salida (lugar desde el que está prevista la salida de un transporte).

La EF y la EFP deben poder acceder fácilmente a los datos siguientes en forma de datos almacenados en bases de datos:

— unidad de transporte, identificación, tamaño y tipo,

— capacidad de la unidad utilizada,

— peso total [peso (masa) total reservado/real de las mercancías, incluidos embalajes y equipos transportadores],

— indicación de mercancías peligrosas.

4.2.8.3. Mensaje «Aviso de salida del vagón»

Objeto: EF a EFP: la empresa ferroviaria comunicará a la empresa ferroviaria principal la fecha y hora en que el vagón ha salido del lugar de salida.

Estos eventos deben almacenarse en la base de datos operativa de vagones y unidades intermodales.

Con el intercambio de este mensaje, la responsabilidad del vagón pasa del cliente a la empresa ferroviaria.

Datos principales:

— número de vagón,

— lugar, fecha y hora de salida (lugar desde el que está prevista la salida de un transporte).

La EF y la EFP deben poder acceder fácilmente a los datos siguientes en forma de datos almacenados en bases de datos:

— unidad de transporte, identificación, tamaño y tipo,

— capacidad de la unidad utilizada,

— peso total [peso (masa) total reservado/real de las mercancías, incluidos embalajes y equipos transportadores],

— indicación de mercancías peligrosas.

4.2.8.4. Mensaje «Llegada al depósito de vagones»

Objeto: la EF comunicará a la EFP que el vagón ha llegado a su depósito. Este mensaje puede basarse en el mensaje «Información del tren en circulación» del apartado 4.2.4 (Previsión de circulación del tren). Este evento debe almacenarse en la base de datos operativa de vagones y unidades intermodales.

Datos principales:

— número de vagón,

— identificación del depósito de llegada,

— fecha y hora de llegada al depósito.

4.2.8.5. Mensaje «Salida del depósito de vagones»

Objeto: la EF comunicará a la EFP que el vagón ha abandonado su depósito. Este mensaje puede basarse en el mensaje «Información del tren en circulación» del apartado 4.2.4 (Previsión de circulación del tren). Este evento debe almacenarse en la base de datos operativa de vagones y unidades intermodales.

Datos principales:

— número de vagón,

— identificación del depósito de salida,

— fecha y hora de salida del depósito.

4.2.8.6. Mensaje de excepción del vagón

Objeto: la EF debe informar a la EFP si ocurre algo inesperado al vagón que pueda afectar a la ETI/ ETA o que requiera acciones adicionales. En la mayoría de los casos, este mensaje requiere además un nuevo cálculo de la ETI/ETA. Si la EFP decide aplicar una nueva ETI/ETA, enviará una respuesta a la EF que le haya enviado el mensaje, junto con la indicación «Solicitud ETI/ ETA» («Mensaje de excepción del vagón, solicitud nueva ETI/ETA»). El cálculo de la nueva ETI/ETA debe seguir el procedimiento del apartado 4.2.7 [Hora prevista de intercambio (ETI)/Hora prevista de llegada (ETA) de un envío].

Esta información debe almacenarse en la base de datos operativa de vagones y unidades intermodales.

Datos principales:

— número de vagón,

— lugar, fecha y hora del trastorno (lugar donde ocurre algo imprevisto durante el transporte),

— código de razón/trastorno.

Además, los datos siguientes deben estar fácilmente accesibles en las bases de datos:

— identificación de la unidad de transporte,

— indicación de mercancías peligrosas.

4.2.8.7. Mensaje de excepción del vagón, solicitud nueva ETI/ETA

Objeto: la EFP podrá enviar este mensaje a la empresa ferroviaria que haya enviado el «Mensaje de excepción» para solicitar el cálculo de una nueva ETI/ETA. La EFP enviará este mensaje, además, a todas las empresas ferroviarias siguientes para comunicarles las desviaciones. La necesidad de calcular una nueva ETI/ETA depende de la EFP y no es necesaria en ningún caso.

Datos principales:

— número de vagón,

— lugar, fecha y hora del trastorno (lugar donde ocurre algo imprevisto durante el transporte),

— código de razón/trastorno,

— solicitud de nueva ETI/ETA.

Además, los datos siguientes deben estar fácilmente accesibles en las bases de datos:

— identificación de la unidad de transporte,

— indicación de mercancías peligrosas.

4.2.8.8. Mensaje «Aviso de llegada del vagón»

Objeto: la última empresa ferroviaria dentro de una cadena de transporte formada por vagones o unidades intermodales comunicará a la empresa ferroviaria principal que el vagón ha llegado a su depósito (locales de la empresa ferroviaria).

Datos principales:

— número de vagón,

— identificación del depósito de la empresa ferroviaria,

— fecha y hora de llegada.

4.2.8.9. Mensaje «Aviso de entrega del vagón en destino»

Objeto: la última empresa ferroviaria dentro de una cadena de transporte formada por vagones comunicará a la empresa ferroviaria principal que el vagón ya está situado en el apartadero del consignatario.

Datos principales:

— número de vagón,

— identificación de la ubicación en los apartaderos del consignatario (localización, zona, vía, surco),

— fecha y hora de colocación.

El aviso de entrega del vagón puede enviarse por segunda vez como «Confirmación de entrega del vagón en destino», con los siguientes datos adicionales.

— identificador del cliente.

Observación: en el modo de acceso abierto, el movimiento del vagón descrito es un proceso interno de la EF. No obstante, ésta debe efectuar todos los cálculos y el almacenamiento de datos, ya que la EFP es quien tiene un contrato y un compromiso con el cliente.

El diagrama secuencial de estos mensajes, basado en el ejemplo 1 del cálculo de la ETI para los vagones 1 y 2 (véase el apartado 4.2.7.2: Cálculo de la ETI y la ETA) está integrado en el diagrama del aviso de intercambio en el anexo A, índice 5, capítulo 6.

4.2.9. Avisos de intercambio

4.2.9.1. Observaciones preliminares

Los avisos de intercambio describen los mensajes que acompañan a la transferencia de responsabilidad sobre un vagón entre dos empresas ferroviarias, la cual tiene lugar en los puntos de intercambio. También instan a la nueva empresa ferroviaria a realizar el cálculo de la ETI y a seguir el proceso descrito en el apartado 4.2.7 [Hora prevista de intercambio (ETI)/Hora prevista de llegada (ETA) de un envío].

Deben intercambiarse los siguientes mensajes:

— aviso de intercambio del vagón,

— aviso de intercambio del vagón/Sub,

— aviso de recepción del vagón en el punto de intercambio,

— aviso de rechazo del vagón en el punto de intercambio Los datos de estos mensajes deben almacenarse en la base de datos operativa de vagones y unidades intermodales.

En caso de desviación, deberá generarse una nueva ETI/ETA y comunicarse de acuerdo con el proceso descrito en el apartado 4.2.7: Hora prevista de intercambio (ETI)/Hora prevista de llegada (ETA) de un envío. El diagrama secuencial de estos mensajes se incluye, en relación con los mensajes de movimiento de vagones, en el anexo A, índice 5, capítulo 6.

Los avisos de intercambio de vagones y los avisos de intercambio de vagones/Sub, así como los mensajes de recepción de vagones, pueden transmitirse en forma de lista de varios vagones, en especial si todos estos vagones forman parte del mismo tren. En este caso, todos los vagones podrán relacionarse en un solo mensaje.

En caso de acceso abierto, no hay puntos de intercambio. En un punto de manipulación, la responsabilidad de los vagones no cambia. Por lo tanto, no es necesario el intercambio de mensajes especiales. Sin embargo, a partir de la información sobre el tren en circulación en este punto de notificación, deberá procesarse la información sobre la ubicación, fecha y hora de salida y llegada del vagón o unidad intermodal, y almacenarse en la base de datos operativa de vagones y unidades intermodales.

El contenido de estos mensajes es el que se describe a continuación.

4.2.9.2. Mensaje «Aviso de intercambio del vagón»

Objeto: mediante el «Aviso de intercambio del vagón», una empresa ferroviaria (EF 1) pregunta a la siguiente empresa ferroviaria (EF 2) de la cadena de transporte si acepta la responsabilidad sobre un vagón. Con el «Aviso de intercambio del vagón/Sub», la EF 2 informa a su AI de que ha aceptado la responsabilidad.

Datos principales:

— número de vagón,

— número de tren (sólo si el vagón está en un tren),

— lugar, fecha y hora del intercambio.

Además, los datos siguientes deben estar fácilmente accesibles en las bases de datos:

— identificación de la unidad de transporte (número, tamaño y tipo),

— peso total [peso (masa) total reservado/real de las mercancías, incluidos embalajes y equipos transportadores],

— capacidad de la unidad utilizada,

— detalles de las mercancías peligrosas, identificador.

4.2.9.3. Mensaje «Aviso de intercambio del vagón/Sub»

Objeto: con el «Aviso de intercambio del vagón/Sub», la EF 2 informa al AI de que ha aceptado la responsabilidad de un determinado vagón.

Datos principales:

— número de vagón,

— número de tren (sólo si el vagón está en un tren),

— lugar, fecha y hora del intercambio.

Además, los datos siguientes deben estar fácilmente accesibles en las bases de datos:

— detalles de las mercancías peligrosas, identificador.

4.2.9.4. Mensaje «Aviso de recepción del vagón en e l punto de intercambio»

Objeto: mediante el «Aviso de recepción del vagón en el punto de intercambio», la EF 2 comunica a la EF 1 que acepta la responsabilidad sobre el vagón.

Datos principales:

— número de vagón,

— lugar, fecha y hora del intercambio.

4.2.9.5. Mensaje «Aviso de rechazo del vagón en el punto de intercambio»

Objeto: mediante el «Aviso de rechazo del vagón en el punto de intercambio», la EF 2 comunica a la EF 1 que no acepta la responsabilidad sobre el vagón.

Datos principales:

— número de vagón,

— lugar, fecha y hora del intercambio,

— código de razón del rechazo,

— descripción adicional (opcional).

4.2.10. Intercambio de información para mejorar la calidad

Para ser competitivo, el sector ferroviario europeo debe prestar a sus clientes un servicio de calidad superior (véase también el anexo III, apartado 2.7.1, de la Directiva 2001/16/CE).

Es indispensable llevar a cabo un proceso de evaluación después del viaje para apoyar mejoras de la calidad.

Además de evaluar el servicio prestado al cliente, las EFP, las EF y los AI deberán evaluar la calidad de los componentes del servicio que conforman la totalidad del producto ofrecido al cliente.

En el proceso participan los AI y las EF (en especial si se trata de EFP), que seleccionan un parámetro de calidad concreto, un itinerario o ubicación y un período de evaluación en el cual han de compararse los resultados obtenidos con criterios predeterminados, que normalmente se establecen por contrato.

Los resultados del proceso de evaluación deben mostrar claramente el grado de cumplimiento de los objetivos acordados entre las partes contratantes.

Los informes de evaluación deben alcanzar un grado de detalle suficiente para permitir un análisis que revele el lugar y la causa aparente de las mermas de calidad, como por ejemplo un retraso. Entonces deberán analizarse las causas últimas de los fallos de calidad reiterados, a fin de que las partes contratantes puedan adoptar medidas correctivas.

Es obligación del AI y de la EF aportar datos, participar en el análisis de las causas, incluso con terceros, y aplicar las medidas correctivas que se acuerden.

El proceso de evaluación tendrá carácter repetitivo.

Para evaluar la calidad, los mensajes ya definidos pueden utilizarse tal como se indica en los seis epígrafes siguientes:

1. EFP/Cliente: tiempo de tránsito, ETA, resolución de alertas

En los contratos entre las empresas ferroviarias que actúan como integradoras de servicios (EFP) y los clientes podrán asumirse compromisos (en función del contrato respectivo) en materia de tiempo de tránsito, hora prevista de llegada (ETA) y resolución de alertas. Los mensajes más importantes para esta evaluación de calidad son:

— aviso de liberación,

— aviso de salida,

— aviso de entrega en destino.

2. EFP/Proveedores de servicios: tiempos de tránsito y manipulación, ETA, ETI, códigos de razones

En los contratos entre una EFP y otros proveedores de servicios de transporte se podrán asumir compromisos en materia de tiempos de tránsito (en horas), de la manera siguiente:

— tiempo entre la liberación de un vagón/entrega de un envío y la entrega en punto de intercambio,

— tiempo entre la recogida del envío en el local del cliente y la entrega en punto de entrada al depósito,

— tiempo entre la entrega en el punto de entrada al depósito y la carga,

— tiempo entre la recepción en un punto de intercambio y la entrega en el punto de intercambio siguiente,

— tiempo entre la recepción y la carga/colocación en un punto de intercambio,

— tiempo entre la maniobra y la entrega en destino.

Los mensajes más importantes para esta evaluación de calidad son:

— aviso de liberación,

— aviso de salida,

— llegada a depósito,

— salida de depósito,

— aviso de llegada,

— entrega de intercambio del vagón,

— vagón recibido en el punto de intercambio,

— vagón rechazado en el punto de intercambio.

3. EF/AI: puntualidad del tren, hora prevista de llegada del tren (ETA-T), hora prevista de transferencia (ETH)

En los contratos entre las EF y los AI puede especificarse un nivel de puntualidad para los horarios de trenes en los puntos de notificación especificados, al igual que la exactitud de las ETA y ETH de los trenes. Los mensajes más importantes para esta evaluación de calidad son:

— previsión de circulación del tren,

— información sobre el tren en circulación,

— consulta/respuesta sobre retraso/puntualidad del tren.

4. EF/AI: disponibilidad del surco/surco planificado

En los contratos entre empresas ferroviarias y administradores de la infraestructura se describirán claramente la disponibilidad de surcos ferroviarios en términos de tramos horarios en puntos determinados. Estos contratos también recogerán las especificaciones de longitud máxima y peso bruto, gálibo de carga, etc. Este aspecto se tratará en el epígrafe 6 (AI/EF: Calidad de la composición del tren).

Asimismo, estos contratos estipularán los procedimientos y plazos para confirmar la utilización de un surco o cancelar un surco previsto, así como la medida en que un surco podrá utilizarse fuera (antes o después) de los tramos horarios especificados. Los mensajes más importantes para esta evaluación de calidad son:

— cancelación de surco,

— surco no disponible.

5. EF/AI: disponibilidad de surcos para uso inminente

Si una EF desea hacer circular un tren fuera de los límites de tiempo establecidos para un surco planificado, deberá enviar una solicitud de surco para uso inminente a los AI implicados (tal como dispone la Directiva 2001/14/CE).

La empresa ferroviaria comprobará periódicamente las solicitudes de surcos con los datos de las respuestas a fin de elaborar los siguientes informes:

— tiempo de respuesta a las solicitudes de surco según lo establecido en el acuerdo marco,

— número de surcos suministrados en determinados períodos de tiempo, en el plazo solicitado,

— número de solicitudes de surcos denegadas.

Los mensajes más importantes para esta evaluación de calidad son:

— solicitud de surco,

— datos del surco,

— rechazo de datos del surco,

— cancelación de surco,

— surco no disponible.

6. AI/EF: calidad de la composición del tren

Cuando una EF envía el mensaje de tren listo y/o la lista de composición del tren a uno o varios AI (o a otras EF), estas notificaciones deberán coincidir con las especificaciones del tren contempladas en el contrato correspondiente.

Para comprobar este cumplimiento y, por consiguiente, para evaluar la calidad de la composición del tren, los mensajes más importantes son:

— composición del tren,

— tren inadecuado.

4.2.11. Principales datos de referencia

4.2.11.1. Prefacio

Los datos de la infraestructura (las declaraciones de red y los datos almacenados en la base de datos de avisos de restricciones en las infraestructuras) y los datos del material rodante (almacenados en las bases de datos de referencia del material rodante y en la base de datos operativa de vagones y unidades intermodales) son los más importantes para la explotación de trenes de mercancías en la red europea. Conjuntamente, ambos tipos de datos permiten evaluar la compatibilidad del material rodante con la infraestructura, contribuyen a evitar la introducción múltiple de datos, lo cual aumenta especialmente la calidad de los mismos, y ofrecen una imagen clara de todas las instalaciones y equipos disponibles en un momento determinado para tomar decisiones rápidas durante la explotación.

4.2.11.2. Bases de datos de avisos de restricciones en las infraestructuras

Cada AI es responsable de la idoneidad de un surco en su infraestructura y la EF está obligada a cotejar las características del tren con los valores indicados en los datos de su surco contratado.

Sin perjuicio de las condiciones de uso de un surco establecidas en las declaraciones de la red o de las responsabilidades en el caso de que se produzca alguna de las restricciones en la infraestructura, expuestas en la ETI «Explotación y gestión del tráfico», la empresa ferroviaria debe saber, antes de preparar el tren, si hay alguna restricción en los segmentos de línea o estaciones (nodos) que afecten a su composición del tren descrita en el contrato de surco.

Para ello, los administradores de la infraestructura deben instalar y alimentar las bases de datos de avisos de restricciones en la infraestructura. La estructura de esta base de datos se describe en el anexo A, índice 2. Las entradas en estas bases de datos se basan en segmentos acordes con las respectivas declaraciones de la red, con el añadido de la información sobre restricciones. Estas bases de datos han de ser accesibles a través de la interfaz común (4.2.14.1: Arquitectura general y 4.2.14.7: Interfaz común).

La empresa ferroviaria está obligada a tener en cuenta todas las restricciones que figuran en la base de datos de avisos sobre restricciones en la infraestructura que afecten a su tren en circulación hasta el período previo a la salida. Si no se dispone otra cosa en el contrato entre el administrador de la infraestructura y la empresa ferroviaria, el período previo a la salida comenzará una hora antes de la hora prevista de salida.

Durante el período previo a la salida, el administrador de la infraestructura deberá comunicar directamente a la empresa ferroviaria cualquier cambio de importancia que aparezca en la base de datos de avisos de restricciones en la infraestructura.

4.2.11.3. Bases de datos de referencia de material rodante

El poseedor de un elemento de material rodante se encarga del almacenamiento de los datos correspondientes en una base de datos de referencia de material rodante.

La información que debe incluirse en las distintas bases de datos de referencia de material rodante se detalla en el anexo A, índice 2. Debe contener todos los elementos para:

— la identificación del material rodante,

— la evaluación de la compatibilidad con la infraestructura,

— la evaluación de las características de carga pertinentes,

— el conocimiento de las características relacionadas con los frenos,

— el conocimiento de los datos de mantenimiento,

— el conocimiento de las características ambientales.

Las bases de datos de referencia de material rodante deben permitir un acceso fácil (un solo acceso común a través de la interfaz común) a los datos técnicos, a fin de minimizar el volumen de datos transmitidos por cada operación. El contenido de las bases de datos deberá ser accesible y estar basado en una estructura de derechos de acceso en función de los privilegios concedidos a todos los prestadores de servicios (administradores de la infraestructura, empresas ferroviarias, proveedores de servicios de logística y gestores de flotas), en particular para los fines de gestión de flotas y mantenimiento del material rodante.

Las entradas de la base de datos de referencia de material rodante pueden agruparse de la manera siguiente:

— datos administrativos,

relacionados con aspectos de certificación y registro, como la referencia al expediente de registro comunitario, el identificador del organismo notificado, etc.; pueden incluirse datos históricos sobre propiedad, alquiler, etc. Deberán tenerse en cuenta las fases siguientes:

— certificación «CE»,

— registro en el Estado de origen,

— fecha de puesta en servicio en el Estado de registro,

— registro en otros países para uso en su red nacional,

— certificación de seguridad de todo el material rodante que no se ajuste a la ETI «Material rodante».

El poseedor del material rodante está obligado a asegurarse de que estén disponibles estos datos y de que se hayan realizado los procesos correspondientes.

— datos de diseño,

que abarcarán todos los elementos (físicos) constitutivos del material rodante, incluidas las características relacionadas con el medio ambiente y toda la información que previsiblemente siga siendo válida durante toda la vida útil del material rodante; esta parte puede contener un historial de importantes reformas, principales operaciones de mantenimiento, revisiones generales, etc.

4.2.11.4. Da tos de explotac ión de l mate r ia l rodante Además de los datos de referencia del material rodante, los datos que representan el estado real de dicho material son los más importantes de cara a la explotación.

Estos datos incluirán datos temporales, como restricciones, operaciones de mantenimiento en curso y previstas, kilometraje e historial de averías, etc.; y todos los datos que puedan considerarse de «estado» (restricciones temporales de velocidad, freno desconectado, necesidades de reparación y descripción de averías, etc.).

Para utilizar los datos de funcionamiento del material rodante hay que tener en cuenta las tres diferentes entidades responsables del material rodante durante la operación de transporte.

— la empresa ferroviaria, responsable del riesgo mientras el transporte está bajo su control,

— el poseedor del material rodante, y

— el usuario (arrendatario) del material rodante.

Estas tres partes deben tener un usuario autorizado para acceder a los datos de explotación del material rodante, en función de su nivel de autorización predefinido, por medio de la clave única que acompaña al identificador del vagón (número de vagón).

Los datos de explotación del material rodante forman parte de la base de datos europea de explotación de vagones y unidades intermodales, descrita en el apartado 4.2.12.2: Otras bases de datos.

4.2.12. Varios archivos de referencia y bases de datos

4.2.12.1. Archivos de referencia

Para la explotación de trenes de mercancías en la red europea, los siguientes archivos de referencia deben estar disponibles y accesibles para todos los proveedores de servicios (administradores de infraestructuras, empresas ferroviarias, prestadores de servicios de logística y gestores de flota). Los datos deberán reflejar la situación real en todo momento.

Depositado y administrado localmente:

— archivo de referencia de los servicios de emergencia por tipo de mercancías peligrosas.

Depositados y administrados centralizadamente:

— archivo de referencia de los códigos correspondientes a todos los administradores de infraestructuras, empresas ferroviarias y empresas proveedoras de servicios,

— archivo de referencia de los códigos correspondientes a los clientes de servicio de transporte,

— archivo de referencia de los códigos correspondientes a los puntos de ubicación (primarios, secundarios y de rastreo de zona),

— archivo de referencia de los códigos correspondientes a los puntos de ubicación de los clientes,

— archivo de referencia de todos los sistemas de control de trenes existentes,

— archivo de referencia de mercancías peligrosas y números ONU y RID,

— archivo de referencia de todos los tipos de locomotoras,

— archivo de referencia de todos los códigos CN y HS correspondientes a mercancías,

— archivo de referencia de todos los talleres de mantenimiento europeos,

— archivo de referencia de todos los organismos de control europeos,

— archivo de referencia de todos los operadores con licencia europea, incluida la lista respectiva de certificados nacionales de seguridad otorgados.

Está pendiente la codificación de los administradores de infraestructuras, empresas ferroviarias, organizaciones y empresas de transporte y clientes de servicios de transporte, así como de los puntos de ubicación (primarios y subsidiarios, etc.), incluidos los correspondientes a clientes.

4.2.12.2. Otras base s de datos

A fin de poder seguir los movimientos de trenes y vagones deberán instalarse las siguientes bases de datos, que se actualizarán en tiempo real con cada evento pertinente: las entidades autorizadas, como los poseedores de material rodante y los gestores de flota, deben tener acceso a los datos necesarios para el desempeño de sus funciones, conforme a las condiciones contractuales:

— base de datos operativa de vagones y unidades intermodales,

— plan de viaje de vagones/unidades intermodales.

Estas bases de datos han de ser accesibles a través de la interfaz común (4.2.14.1: Arquitectura general y 4.2.14.7: Interfaz común).

Base de datos operativa de vagones y unidades intermodales

La comunicación entre la EFP y las demás empresas ferroviarias en la modalidad de cooperación se basa en los números de vagón o de unidad intermodal. Por consiguiente, una empresa ferroviaria que se comunique con los administradores de infraestructuras en relación con un tren deberá desglosar esta información en vagones y unidades intermodales. Esta información desglosada deberá almacenarse en la base de datos operativa de vagones y unidades intermodales. La información sobre el movimiento del tren dará lugar a nuevas entradas o actualizaciones en la base de datos mencionada para mantener informado al cliente. La parte relativa al movimiento de un vagón o unidad intermodal se configura en la base de datos, a más tardar, cuando se recibe la hora de liberación de los vagones o unidades intermodales del cliente. Esta hora de liberación constituye la primera entrada de movimiento de un vagón en la base de datos operativa de vagones y unidades intermodales en relación con un determinado trayecto de transporte. Los mensajes relativos al movimiento del vagón están definidos en los apartados 4.2.8 (Movimiento de vagones) y 4.2.9 (Avisos de intercambio). Estas bases de datos han de ser accesibles a través de la interfaz común (4.2.14.1: Arquitectura general y 4.2.14.7: Interfaz común).

La base de datos operativa de vagones y unidades intermodales es la más importante para el seguimiento de los vagones y, por lo tanto, para la comunicación entre la EFP y el resto de empresas ferroviarias implicadas. Esta base de datos refleja el movimiento de un vagón y de una unidad intermodal desde la salida hasta la entrega final en los apartaderos del cliente, con indicación de las horas previstas de intercambio (ETI) y las horas efectivas en distintos lugares hasta la hora prevista de llegada (ETA) al punto de entrega final. Esta base de datos también refleja distintos estados del material rodante, como por ejemplo:

— estado: carga del material rodante.

Este estado es necesario para el intercambio de información entre la empresa ferroviaria y los administradores de la infraestructura y otras empresas ferroviarias que puedan intervenir en el trayecto de transporte,

— estado: vagón cargado en trayecto.

Este estado es necesario para el intercambio de información entre el AI y la EF, así como con otros administradores de la infraestructura y otras empresas ferroviarias que puedan intervenir en el trayecto de transporte,

— estado: vagón vacío en trayecto.

Este estado es necesario para el intercambio de información entre el AI y la EF, así como con otros administradores de la infraestructura y empresas ferroviarias que puedan intervenir en el trayecto de transporte,

— estado: descarga del material rodante.

Este estado es necesario para el intercambio de información entre la empresa ferroviaria en destino y la EFP encargada del transporte,

— estado: vagón vacío bajo control del gestor de flota.

Este estado es necesario para obtener la información sobre disponibilidad de un vehículo de características determinadas.

Bases de datos de planes de viaje de los vagones

Normalmente, los trenes transportan vagones de varios clientes. Para cada vagón, la empresa ferroviaria principal (es decir, la empresa ferroviaria que desempeña la función de integradora de servicios) establecerá y actualizará un plan de viaje correspondiente al surco ferroviario de cada tren. La asignación de nuevos surcos a un tren — por ejemplo, en caso de interrupción del servicio— dará lugar a la revisión del plan de viaje de los vagones afectados.

La hora de creación de este plan de viaje será la hora de recepción de la carta de porte del cliente.

Los planes de viaje de los vagones deben ser almacenados por cada EFP en una base de datos. Estas bases de datos han de ser accesibles a través de la interfaz común (4.2.14.1: Arquitectura general y 4.2.14.7: Interfaz común).

Observación:

Además de las bases de datos obligatorias antes mencionadas, podrá instalarse una base de datos de trenes en cada administrador de la infraestructura.

La base de datos de trenes del AI se corresponde con la parte de movimientos de la base de datos operativa de vagones y unidades intermodales. Los principales datos introducidos serán los datos del tren incluidos en el mensaje de composición enviado por la empresa ferroviaria. Todos los eventos relacionados con el tren darán lugar a una actualización de la base de datos de trenes. La base de datos de surcos será otra posibilidad para almacenar estos datos (4.2.2: Solicitud de surco). Estas bases de datos han de ser accesibles a través de la interfaz común (4.2.14.1: Arquitectura general y 4.2.14.7: Interfaz común).

4.2.12.3. Requisitos adicionales de las bases de datos

A continuación se relacionan los requisitos adicionales que deben cumplir las distintas bases de datos.

Son los siguientes:

1. Autenticación

La base de datos debe disponer de un proceso de autenticación para dar acceso a los usuarios de los sistemas.

2. Seguridad

La base de datos debe contar con elementos de seguridad para controlar el acceso a la base de datos. No es obligatorio encriptar el contenido de la base de datos.

3. Coherencia

La base de datos seleccionada debe admitir la aplicación del principio ACID, acrónimo de «Atomicity, Consistency, Isolation, Durability» (atomicidad, coherencia, aislamiento y durabilidad).

4. Control de acceso

La base de datos debe permitir que los usuarios o sistemas autorizados tengan acceso a los datos. Se dispondrá de un procedimiento de control de acceso hasta el nivel de un único atributo de un registro de datos. La base de datos debe admitir el uso de controles de acceso configurables, basados en perfiles predefinidos, que permitan la introducción, actualización o eliminación de registros de datos.

5. Rastreo

La base de datos debe contar con un sistema de registro de todas las acciones realizadas en ella, que permita un seguimiento detallado de la introducción de datos (autor, contenido, fecha y hora).

6. Estrategia de bloqueo

La base de datos debe disponer de una estrategia de bloqueo que permita acceder a los datos aunque otros usuarios estén modificando registros en ese momento.

7. Acceso múltiple

La base de datos debe admitir que varios usuarios y sistemas accedan a los datos al mismo tiempo.

8. Fiabilidad

La fiabilidad de la base de datos debe garantizar la disponibilidad requerida.

9. Disponibilidad

La base de datos debe ofrecer una disponibilidad mínima del 99,9 %.

10. Facilidad de mantenimiento

Las características de mantenimiento de la base de datos deben ajustarse a la disponibilidad requerida.

11. Seguridad

Las bases de datos propiamente dichas no están relacionadas con la seguridad. De ahí que los aspectos de seguridad no sean pertinentes. Esto no ha de confundirse con el hecho de que los datos —por ejemplo, si son incorrectos o no están actualizados— puedan afectar a la seguridad de explotación de un tren.

12. Compatibilidad

La base de datos debe admitir un lenguaje de manipulación de datos ampliamente aceptado, como SQL o XQL.

13. Facilidad de importación

La base de datos deberá permitir la importación de datos formateados para su alimentación, en lugar de la introducción manual.

14. Facilidad de exportación

La base de datos deberá permitir la exportación de su contenido en su totalidad o en parte como datos formateados.

15. Campos obligatorios

La base de datos deberá permitir el uso de los campos obligatorios que sea necesario cumplimentar para aceptar el registro correspondiente.

16. Controles de verosimilitud

La base de datos deberá admitir controles configurables de verosimilitud antes de aceptar la introducción, actualización o eliminación de datos.

17. Tiempos de respuesta

La base de datos deberá contemplar tiempos de respuesta que permitan que los usuarios incluyan, actualicen o eliminen datos oportunamente.

18. Aspectos de rendimiento

La base de datos deberá permitir la formulación de las consultas necesarias para la ejecución de 60 000 trayectos de trenes cada 24 horas. Se considerará que aproximadamente la mitad de estos trayectos se realizan en dos horas.

El número y tipo de consultas o actualizaciones por tren dependerá del proceso global de planificación y circulación del tren.

19. Aspectos de capacidad

La base de datos admitirá el almacenamiento de los datos relativos a todos los vagones de mercancías y sobre la red. Será posible ampliar la capacidad por medios sencillos (es decir, añadiendo capacidad de almacenamiento y ordenadores). Para la ampliación de la capacidad no será necesario sustituir el subsistema.

20. Datos históricos

La base de datos deberá permitir la gestión de los datos históricos, es decir, facilitar los datos que ya se han transferido a un archivo.

21. Estrategia de copias de seguridad

Se establecerá una estrategia de realización de copias de seguridad para garantizar que la totalidad del contenido de la base de datos pueda recuperarse en un plazo máximo de 24 horas.

22. Aspectos comerciales

El sistema de base de datos que se utilice será un producto comercialmente disponible (commercially-off-theshelf, COTS) o un producto de dominio público (fuente abierta).

Observaciones:

Los requisitos señalados deberán cumplirse en un sistema estándar de gestión de bases de datos (Database Management System, DBMS).

El uso de las distintas bases de datos está integrado en diversos flujos de trabajo descritos anteriormente. El flujo de trabajo general es un mecanismo de solicitud/respuesta en el que un interesado solicita información de la base de datos a través de la interfaz común (4.2.14.1: Arquitectura general y 4.2.14.7: Interfaz común). El DBMS responderá a esta petición facilitando los datos solicitados o indicando que no es posible facilitar datos (bien porque no existan, bien porque se deniegue el acceso por motivos de control de acceso).

4.2.13. Transmisión electrónica de documentos

En el apartado 4.2.14 (Redes y comunicaciones) se describe la red de comunicaciones que se utilizará para el intercambio de datos. Esta red y las medidas de seguridad descritas permitirán cualquier tipo de transmisión por red, como correo electrónico, transferencia de archivos (ftp, http), etc. Las partes que intervengan en el intercambio de información podrán decidir entonces de qué tipo será, lo que significa que la transmisión electrónica de documentos se realizará, por ejemplo, a través del protocolo FTP.

4.2.14. Redes y comunicaciones

4.2.14.1. Arquitectura general

En este subsistema se producirá, con el tiempo, el crecimiento e interacción de una comunidad telemática de interoperabilidad ferroviaria grande y compleja, con cientos de participantes (empresas ferroviarias, administradores de infraestructuras, etc.), que competirán o colaborarán para atender a las necesidades del mercado.

La infraestructura de redes y comunicaciones que permita el funcionamiento de esta comunidad de interoperabilidad ferroviaria se basará en una «arquitectura de intercambio de información común», que conocerán y adoptarán todos los participantes.

La arquitectura de intercambio de información propuesta:

— estará concebida de modo que compatibilice los distintos modelos de información mediante una transformación semántica de los datos intercambiados entre los sistemas y la conciliación de las diferencias de protocolos entre procesos empresariales o aplicaciones,

— tendrá el menor efecto posible sobre las arquitecturas informáticas utilizadas por cada uno de los participantes,

— protegerá las inversiones ya efectuadas en tecnologías de la información (TI).

La arquitectura de intercambio de información favorece una interacción de tipo horizontal entre todos los participantes, y garantizará al mismo tiempo la integridad y coherencia globales de la comunidad de interoperabilidad ferroviaria mediante la prestación de una serie de servicios centralizados.

Un modelo de interacción horizontal permite distribuir mejor los costes entre los distintos participantes en función del uso efectivo y presenta menos problemas de escalabilidad en general. En el anexo A, índice 5, apartado 1.5 se incluye una representación gráfica de la arquitectura general.

4.2.14.2. Red

En este caso, el término «trabajo en red» se refiere al método y la filosofía de comunicación, y no a la red física.

La interoperabilidad ferroviaria se basa en una arquitectura de intercambio de información común, conocida y adoptada por todos los participantes, que fomenta y elimina barreras para la entrada de nuevos operadores, sobre todo clientes.

Por consiguiente, la cuestión de la seguridad no deberá ser resuelta por la red (VPN, tunelización electrónica, etc.), sino mediante el intercambio y gestión de mensajes intrínsecamente seguros. Por lo tanto, no es necesaria una red VPN (la administración de una gran red VPN sería compleja y costosa), evitándose así los problemas de responsabilidad y atribución de propiedad. No se considera que la tunelización electrónica sea un medio necesario para lograr el nivel de seguridad adecuado.

En todo caso, si algunos participantes ya poseen o desean aplicar diversos grados de seguridad en determinadas partes de la red, podrán hacerlo.

A través de la red pública Internet es posible instalar un modelo horizontal híbrido con un «depósito de datos central» y una «interfaz común» en el nodo de cada participante.

Primero se accederá al depósito de datos central para obtener metainformación, como la identidad del miembro (demandante) en el que está almacenada cierta información, o bien para verificar las credenciales de seguridad.

A continuación se establecerá una comunicación horizontal entre los demandantes implicados.

4.2.14.3. Protocolos

Sólo se utilizarán protocolos que pertenezcan a la serie de protocolos de Internet.

TABLA OMITIDA EN PÁGINA 45

4.2.14.4. Seguridad

Para lograr un alto nivel de seguridad, todos los mensajes deberán ser autónomos, es decir, la información del mensaje estará protegida y el receptor podrá verificar la autenticidad del mensaje. Para ello podrá utilizarse un sistema de encriptado y firma similar al encriptado del correo electrónico. De este modo será posible utilizar cualquier tipo de transmisión por red, como correo electrónico, transferencia de archivos (ftp, http), etc. Las partes implicadas en el intercambio de información podrán elegir entonces el tipo concreto que deseen utilizar.

4.2.14.5. Encriptado

Se utilizará un encriptado asimétrico o una solución híbrida basada en el encriptado simétrico con protección de claves públicas, ya que si varios participantes comparten una clave secreta será inevitable que el sistema falle en algún momento. Se puede alcanzar un nivel más elevado de seguridad si cada participante se hace responsable de su propio par de claves, si bien se requiere un alto nivel de integridad del depósito de datos central (servidor de claves).

4.2.14.6. Depósito de datos central

El depósito de datos central deberá poder procesar:

— metadatos: datos estructurados que describen el contenido de los mensajes,

— la infraestructura de claves públicas (ICP),

— la autoridad de certificación (AC),

— el directorio («guía telefónica»): contiene toda la información necesaria sobre los participantes para intercambiar mensajes.

La gestión del depósito de datos central será responsabilidad de una organización europea de carácter no lucrativo.

4.2.14.7. Interfaz común

La interfaz común será obligatoria para que cada participante pueda ingresar en la comunidad de interoperabilidad ferroviaria.

La interfaz común central deberá poder procesar:

— el formateo de los mensajes salientes de acuerdo con los metadatos,

— la firma y encriptación de los mensajes salientes,

— la dirección de destino de los mensajes salientes,

— la verificación de la autenticidad de los mensajes entrantes,

— la descodificación de los mensajes entrantes,

— los controles de conformidad de los mensajes entrantes de acuerdo con los metadatos,

— la gestión del único acceso común a las distintas bases de datos.

Cada instancia de la interfaz común tendrá acceso a todos los datos necesarios, de acuerdo con la ETI, de cada empresa ferroviaria, administrador de infraestructura, etc., ya sean las bases de datos centralizadas o individuales (véase también el anexo A, índice 5, apartado 1.6).

Podrá efectuarse un nivel mínimo de acuse de recibo en función de los resultados de la verificación de la autenticidad de los mensajes entrantes:

i) acuse de envío positivo (ACK),

ii) acuse de envío negativo (NACK).

La interfaz común utiliza la información que se encuentra en el depósito de datos central para gestionar las tareas antes descritas.

Los participantes podrán utilizar un «espejo» local del depósito de datos central para reducir los tiempos de respuesta.

4.3. Especificaciones funcionales y técnicas de las interfaces

Con arreglo a los requisitos esenciales señalados en el capítulo 3, las especificaciones funcionales y técnicas del subsistema son las siguientes:

4.3.1. Interfaces con la ETI «Infraestructura»

El subsistema «Infraestructura» incluye los sistemas de gestión del tráfico, de posicionamiento y de navegación:

instalaciones técnicas de tratamiento de datos y de telecomunicaciones previstas para el transporte de viajeros de largo recorrido y el transporte de mercancías en esta red con el fin de garantizar un aprovechamiento seguro y armonioso de la red y la gestión eficaz del tráfico.

El subsistema «Aplicaciones telemáticas al servicio del transporte de mercancías» utiliza los datos necesarios con fines de explotación determinados por el contrato de surco y, en su caso, actualizados en la base de datos de avisos de restricciones, que facilita el administrador de la infraestructura. Por consiguiente, no existe una interfaz directa entre la presente ETI y la ETI «Infraestructura».

4.3.2. Interfaces con la ETI «Control y mando y señalización»

La única relación con control y mando y señalización es mediante:

— el contrato de surco, que contiene, en la descripción de los segmentos de la línea, la información pertinente sobre los equipos aplicables de mando y control y señalización, y — varias bases de datos de referencia del material rodante, donde se recogen los equipos de mando y control y señalización del material.

4.3.3. Interfaces con el subsistema «Material rodante»

El subsistema «Aplicaciones telemáticas al servicio del transporte de mercancías» determina los datos técnicos y de explotación que deben estar disponibles para el material rodante.

La ETI «Material rodante» especifica las características de los vagones. Si cambian las características de un vagón, deberán actualizarse en las bases de datos de referencia de material rodante, en el curso del proceso normal de mantenimiento de la base de datos. Por consiguiente, no existe una interfaz directa entre la presente ETI y la ETI «Material rodante».

4.3.4. Interfaces con la ETI «Explotación y gestión del tráfico»

El subsistema «Explotación y gestión del tráfico» especifica los procedimientos y equipamientos asociados que permiten asegurar una explotación coherente de los diferentes subsistemas estructurales, tanto en condiciones de funcionamiento normal como de funcionamiento degradado, incluidas la conducción de los trenes, la planificación y la gestión del tráfico.

El subsistema «Aplicaciones telemáticas al servicio del transporte de mercancías» especifica principalmente las aplicaciones destinadas a los servicios de transporte de mercancías, como el seguimiento en tiempo real de las mercancías y de los trenes y de la gestión de las conexiones con otros modos de transporte.

A fin de asegurar la coherencia entre ambas ETI, se aplicará el siguiente procedimiento.

Cuando se redacten o modifiquen las especificaciones de la ETI «Explotación y gestión del tráfico» relacionadas con los requisitos de la presente ETI, deberá consultarse con el organismo responsable de la presente ETI.

En el caso de que las especificaciones de la presente ETI relacionadas con los requisitos de explotación especificados en la ETI «Explotación y gestión del tráfico» deban ser objeto de alguna modificación, deberá consultarse con el organismo responsable de la ETI «Explotación y gestión del tráfico».

4.4. Normas de funcionamiento

De acuerdo con los requisitos esenciales señalados en el capítulo 3, el subsistema al que se refiere la presente ETI se rige por las siguientes normas de funcionamiento específicas:

4.4.1. Calidad de los datos

A efectos de aseguramiento de la calidad de los datos, el emisor de todo mensaje establecido en la ETI será el responsable de que su contenido sea fidedigno en el momento del envío. Siempre que estén disponibles, deberán utilizarse los datos de las bases de datos establecidas por la ETI.

En caso contrario, será el emisor quien deba controlar la calidad de los datos con sus propios medios.

El aseguramiento de la calidad de los datos incluirá la comparación con los datos de las bases de datos establecidas en la presente ETI, anteriormente descritas, y además, si procede, las comprobaciones lógicas para asegurar la puntualidad y continuidad de los datos y mensajes.

Los datos serán de alta calidad si son aptos para su uso previsto, es decir, si:

— no tienen errores y son accesibles, precisos, puntuales, completos, coherentes con otras fuentes, etc., y

— poseen determinadas características, es decir, si son pertinentes y exhaustivos, si alcanzan un grado de detalle adecuado, si son fáciles de leer y de interpretar, etc.

La calidad de los datos se caracteriza principalmente por su:

— precisión,

— integridad,

— coherencia,

— puntualidad.

Precisión:

La información (datos) que hace falta debe obtenerse del modo más económico posible. Esto sólo es factible si los datos primarios —que desempeñan un papel decisivo en la expedición de un envío, de un vagón o de un contenedor— sólo se registran, a ser posible, en una única ocasión para todo el transporte. Por lo tanto, los datos primarios deben introducirse en el sistema en el punto más próximo posible a su fuente, por ejemplo, en virtud de la carta de porte que se prepara cuando se presenta el envío para el transporte, de forma que puedan integrarse plenamente en cualquier operación de tratamiento posterior.

Integridad:

Antes de enviar un mensaje, deberá comprobarse que esté completo y que su sintaxis sea correcta por medio de los metadatos. De este modo se evita además el tráfico innecesario de información en la red.

También deberá comprobarse la integridad de todos los mensajes recibidos por medio de los metadatos.

Coherencia:

A fin de garantizar la coherencia, se aplicarán normas de práctica empresarial. Deberá evitarse la duplicación de los datos e identificarse claramente al propietario de los mismos.

La forma de aplicar estas normas de práctica empresarial dependerá de la complejidad de la norma. Si las normas son sencillas, bastan las restricciones y los disparadores de la base de datos. Si se utilizan normas más complejas que requieren datos de diversas tablas, deberán aplicarse procedimientos de validación que comprueben la coherencia de la versión de los datos antes de que se generen los datos de la interfaz y de que la nueva versión sea operativa. Deberá garantizarse que los datos transferidos se validen en función de las normas de práctica empresarial definidas.

Puntualidad:

Es importante facilitar la información en el momento oportuno. En la medida en que corresponde directamente al sistema de TI poner en marcha el almacenamiento de datos o el envío de mensajes, la puntualidad no será un problema si el sistema está bien diseñado de acuerdo con las necesidades de los procesos empresariales. Pero en la mayoría de los casos, los mensajes son enviados por un operador o, al menos, se basan en la información adicional aportada por un operador (por ejemplo, el envío de la composición del tren o la actualización de datos relacionados con un tren o vagón). Para cumplir los requisitos de puntualidad, la actualización de los datos debe hacerse lo antes posible, a fin de garantizar que los mensajes que envíe el sistema de forma automática salgan con los datos actualizados.

Con carácter general, deberán cumplirse los siguientes requisitos:

El tiempo de respuesta a consultas deberá ser inferior a 5 minutos. Todas las actualizaciones e intercambios de datos deberán realizarse lo antes posible. El tiempo de reacción y transmisión del sistema para una actualización no deberá exceder de 1 minuto.

Medición de la calidad de los datos

La integridad (porcentaje de campos de datos en los que se han introducido valores) de los datos obligatorios y la coherencia de los datos (porcentaje de valores coincidentes entre tablas/archivos/registros) deben alcanzar el 100 %.

En cuanto a la puntualidad de los datos (porcentaje de datos disponibles en un intervalo de tiempo umbral especificado) debe alcanzarse un 98 %. Los valores umbral que no están definidos en la presente ETI deberán especificarse en los contratos entre las partes implicadas.

Se exigirá una precisión (porcentaje de valores almacenados que son correctos cuando se comparan con el valor real) superior al 90 %. El valor exacto y los criterios correspondientes deberán fijarse en los contratos entre las partes implicadas.

4.4.2. Gestión del depósito de datos central

Las funciones del depósito de datos central están definidas en el apartado 4.2.14.6 (Depósito de datos central). A efectos de aseguramiento de la calidad de los datos, la entidad que gestione el depósito de datos central deberá responsabilizarse de la actualización y de la calidad de los metadatos y del directorio, así como de la administración del control de acceso (claves públicas). En relación con la calidad de los metadatos, debe alcanzarse un porcentaje del 100 % en los parámetros de integridad, coherencia, puntualidad y precisión.

4.5. Normas de mantenimiento

De acuerdo con los requisitos esenciales señalados en el capítulo 3, el subsistema al que se refiere la presente ETI se rige por las siguientes normas de mantenimiento específicas:

La calidad del servicio de transporte debe estar garantizada aunque los equipos de proceso de datos sufran una avería total o parcial. Por consiguiente, es aconsejable instalar sistemas u ordenadores duplicados con un grado especialmente elevado de fiabilidad, de modo que se garantice el funcionamiento ininterrumpido durante el mantenimiento.

Los aspectos relacionados con el mantenimiento de las distintas bases de datos se tratan en el apartado 4.2.12.3 (Requisitos adicionales de las bases de datos), puntos 10 y 21.

4.6. Cualificación profesional

El personal necesario para la explotación y el mantenimiento del subsistema y para la aplicación de la ETI necesita la cualificación profesional que se describe a continuación:

La aplicación de la presente ETI no exige un sistema de hardware y software totalmente nuevo con nuevo personal. El cumplimiento de los requisitos de la ETI sólo da lugar a cambios, mejoras o ampliaciones funcionales de la explotación, tal como ya lo hace el personal existente. Por consiguiente, no hay requisitos adicionales a las normas nacionales y europeas vigentes en materia de cualificación profesional.

En caso de necesidad, una formación complementaria del personal no deberá consistir simplemente en un adiestramiento en el manejo de aparatos. Los miembros del personal deben conocer y comprender la función concreta que deben desempeñar en todo el proceso de transporte. El personal debe ser consciente, en particular, de la necesidad de mantener un elevado nivel de rendimiento, ya que éste es un factor decisivo para la fiabilidad de la información que se procesará en una fase posterior.

La cualificación profesional necesaria para la composición y explotación de trenes está definida en la ETI «Explotación y gestión del tráfico».

4.7. Condiciones de salud y seguridad

A continuación se señalan las condiciones de salud y seguridad del personal necesario para la explotación y el mantenimiento del subsistema en cuestión (o para el ámbito de aplicación técnico definido en el apartado 1.1) y para la aplicación de la ETI:

No existen requisitos adicionales a las normas nacionales y europeas vigentes en materia de salud y seguridad.

4.8. Registros de infraestructuras y material rodante

De acuerdo con el artículo 24, apartado 1, de la Directiva 2001/16/CE, «Los Estados miembros velarán por que se publiquen y actualicen anualmente registros de la infraestructura y del material rodante. Estos registros contendrán, para cada subsistema o parte del subsistema de que se trate, las características principales (por ejemplo, los parámetros fundamentales) y su conformidad con las características prescritas por las ETI aplicables.

Para ello, cada ETI indicará en detalle qué datos deben figurar en los registros de la infraestructura y del material rodante.».

Debido a que estos registros se actualizan y se publican anualmente, no son utilizables en el subsistema «Aplicaciones telemáticas al servicio del transporte de mercancías». Por lo tanto, la presente ETI no tiene nada que indicar en estos registros.

5. COMPONENTES DE INTEROPERABILIDAD

5.1. Definición

De acuerdo con el artículo 2, letra d), de la Directiva 2001/16/CE:

Los componentes de interoperabilidad son «todo componente elemental, grupo de componentes, subconjunto o conjunto completo de materiales incorporados o destinados a ser incorporados en un subsistema, de los que dependa directa o indirectamente la interoperabilidad del sistema ferroviario transeuropeo convencional. El concepto de “componente” engloba no sólo objetos materiales, sino también inmateriales, como los programas informáticos.».

5.2. Lista de componentes

Los componentes de interoperabilidad se regulan por las disposiciones pertinentes de la Directiva 2001/16/CE.

No se han determinado componentes de interoperabilidad en lo que respecta al subsistema «Aplicaciones telemáticas al servicio del transporte de mercancías».

Para cumplir los requisitos de la presente ETI sólo hacen falta equipos informáticos estándar, sin aspectos específicos de la interoperabilidad en el entorno ferroviario. Esto es válido para los componentes de hardware y para el software estándar utilizados, como el sistema operativo y las bases de datos. Cada usuario puede utilizar su propio software de aplicación y adaptarlo y mejorarlo de acuerdo con su funcionalidad y necesidades concretas.

La «arquitectura de integración de aplicaciones» propuesta presupone que las aplicaciones podrían no utilizar el mismo modelo de información interna. La integración de aplicaciones se define como el proceso destinado a lograr que sistemas de aplicación de diseño independiente funcionen correctamente unos con otros.

5.3. Rendimientos y especificaciones de los componentes

Véase el apartado 5.2, no pertinente a los efectos de la ETI «Aplicaciones telemáticas al servicio del transporte de mercancías».

6. EVALUACIÓN DE CONFORMIDAD E IDONEIDAD DE LOS COMPONENTES Y VERIFICACIÓN DEL SUBSISTEMA

6.1. Componentes de interoperabilidad

6.1.1. Procedimientos de evaluación

El procedimiento de evaluación de la conformidad o idoneidad de los componentes de interoperabilidad debe basarse en las especificaciones europeas o en las especificaciones aprobadas en virtud de la Directiva 2001/16/CE.

En lo que respecta a la idoneidad, estas especificaciones indicarán todos los parámetros que será necesario medir, controlar u observar y describirán los métodos de ensayo y procedimientos de medición relacionados, ya sea en un banco de pruebas de simulación o en pruebas realizadas en un entorno ferroviario real.

Procedimientos para la evaluación de la conformidad y la idoneidad:

Lista de especificaciones y descripción de los procedimientos de ensayo:

No pertinente para la ETI «Aplicaciones telemáticas al servicio del transporte de mercancías».

6.1.2. Módulo

A petición del fabricante o de su mandatario establecido en la Comunidad, el procedimiento será llevado a cabo por un organismo notificado con arreglo a lo dispuesto en los módulos pertinentes de la Decisión 93/465/CEE, tal como queda expuesto, modificado y suplementado en el anexo de la presente ETI.

Los módulos deberán combinarse y utilizarse de forma selectiva, según el componente de que se trate.

No pertinente para la ETI «Aplicaciones telemáticas al servicio del transporte de mercancías».

6.2. Subsistema «Aplicaciones telemáticas al servicio del transporte de mercancías»

A petición de la entidad contratante o de su mandatario establecido en la Comunidad, el organismo notificado tramitará la verificación «CE» con arreglo al anexo VI de la Directiva 2001/16/CE.

De acuerdo con el anexo II de la Directiva 2001/16/CE, los subsistemas se desglosan en áreas estructurales y funcionales.

La evaluación de conformidad es obligatoria para las ETI del ámbito estructural. El subsistema «Aplicaciones telemáticas al servicio del transporte de mercancías» pertenece al área funcional y la presente ETI no contempla ningún módulo para la evaluación de conformidad.

Sin embargo, el depósito de datos central y una interfaz común en el nodo de cada agente son la espina dorsal de la integración de aplicaciones. El modelo de intercambio de información se encuentra en el depósito centralizado de integración de aplicaciones, que contiene los metadatos de la interfaz en una localización física. Los metadatos contienen información sobre el contenido de la comunicación (lo que hay en los datos que se envían), las identidades de los puntos de contacto de los emisores y receptores y la mecánica del proceso de interacción de los protocolos empresariales a nivel de la aplicación.

Cabe destacar los siguientes aspectos:

— el depósito de datos central contiene el directorio (guía telefónica) de todos los agentes que participan en el intercambio de mensajes. Este directorio debe reflejar la situación real en todo momento. Las entradas incorrectas resultarán evidentes de forma inmediata. No es necesario ningún procedimiento de evaluación,

— el depósito de datos central también contiene la autoridad de certificación. Éste es principalmente un acto administrativo, que se ejecuta físicamente. Las entradas incorrectas resultarán evidentes de forma inmediata.

No es necesario ningún procedimiento de evaluación,

— el depósito de datos central contiene los metadatos de los mensajes (de acuerdo con el anexo A, índice 1) que sirven de base al intercambio de mensajes en un entorno de información heterogéneo. Los metadatos deben ser administrados y actualizados en el depósito de datos central. Se reconocerá inmediatamente cualquier incompatibilidad de la estructura o del contenido de los mensajes para el envío o recepción de datos y se rechazará la transferencia. No es necesario ningún procedimiento de evaluación,

— la interfaz común en el nodo de cada agente contiene principalmente el «espejo» local del depósito de datos central para acortar el tiempo de respuesta y reducir la carga que soporta el depósito. Deberá asegurarse que las versiones de los datos del depósito de datos central y de la interfaz común sean siempre las mismas. Por lo tanto, la actualización de datos deberá hacerse en el nivel central y las versiones nuevas deberán descargarse desde allí. No es necesario ningún procedimiento de evaluación.

7. PUESTA EN PRÁCTICA

7.1. Modalidades de aplicación de la presente ETI

7.1.1. Introducción

La presente ETI está destinada a prestar apoyo informativo al proceso empresarial del transporte ferroviario de mercancías, a fin de mejorar la calidad de los servicios de transporte. En este sentido, su aplicación es independiente de los conceptos de infraestructura nueva, acondicionada o heredada, o de los activos de material rodante, como es habitual en otras ETI derivadas de la Directiva 2001/16/CE.

Debido a la omnipresencia de sus prescripciones, se trata de una ETI que tendrá efectos profundos sobre los procesos empresariales y operativos de todo el sector ferroviario europeo. Por añadidura, el continuo crecimiento del transporte internacional de mercancías exige que la gestión de la información se realice desde una perspectiva europea. Estos hechos combinados exigen la formulación de un plan coherente de puesta en práctica de la presente ETI en el ámbito transeuropeo. Este plan debe ofrecer una visión tanto de lo que se ha de conseguir con la puesta en práctica de la ETI como de la forma y el momento de pasar del actual marco de sistemas de información fragmentados a una autopista de la información para toda Europa que pueda aportar valor añadido a todas las partes interesadas en el transporte ferroviario: administradores de infraestructuras, empresas ferroviarias, transportistas y, en última instancia, el cliente.

En este contexto, se ha dado en formular el concepto de plan estratégico de despliegue europeo. Este plan define el sistema de objetivos que ha de establecerse a los efectos de la puesta en práctica de la presente ETI, junto con el plan de despliegue en el cual se sustenta y que se describe en el apartado siguiente.

7.1.2. Plan estratégico de despliegue europeo (SEDP)

7.1.2.1. Objetivos del SEDP

El plan estratégico de despliegue europeo (SEDP) persigue tres objetivos:

1) ofrecer una visión de la puesta en práctica de la ETI-ATM en el sector ferroviario europeo;

2) calificar dicha visión desde una perspectiva de viabilidad técnica y económica;

3) establecer un programa de las actividades necesarias para hacer realidad esa visión.

Además de establecer un programa de acción para la puesta en práctica de la ETI-ATM que garantice la visibilidad de todo el proceso, el SEDP debe fijar criterios adecuados para el seguimiento de sus progresos por las distintas partes interesadas —concretamente, los administradores de infraestructuras, las empresas ferroviarias, los transportistas y, en última instancia, el cliente—, de manera que se garantice la defensa de sus intereses. Esto se refiere, en particular, a las inversiones que necesitan movilizar los administradores de infraestructuras y las empresas ferroviarias para el posible acondicionamiento e integración de sus sistemas informáticos heredados y la capacidad de los sistemas basados en la ETI-ATM para responder con eficacia a las cambiantes necesidades de información de los transportistas y clientes.

En este contexto, el SEDP debe constituirse, en última instancia, en un instrumento que permita orientar todo el sector ferroviario europeo hacia el objetivo de desarrollo de un sistema de información paneuropeo, además de facilitar la creación de sinergias, evitar la fragmentación y ayudar a concentrar los recursos limitados en las cuestiones prioritarias, dando mejor respuesta a los objetivos de calidad que son fundamentales en los servicios de transporte.

7.1.2.2. Requisitos del SEDP

La elaboración de un plan de este tipo exigirá un análisis sistemático de las cuestiones técnicas, operativas, económicas e institucionales pertinentes que sustentan el proceso de puesta en práctica de la ETI-ATM, que incluirá, en particular:

1) el inventario de las aplicaciones informáticas propias de cada administrador de infraestructura o empresa ferroviaria que pueden servir de base para crear un sistema paneuropeo capaz de cumplir los requisitos de la ETI-ATM (en adelante, «el sistema ATM»);

2) la definición de los datos funcionales, datos conexos y requisitos de rendimiento necesarios para cumplir la ETI-ATM;

3) el perfil de la arquitectura del sistema ATM, que se basará en el análisis de las configuraciones capaces de integrar los recursos informáticos heredados, ofreciendo, al mismo tiempo, la funcionalidad y prestaciones exigidas: por ejemplo, arquitecturas cliente-servidor centralizadas o distribuidas, o arquitecturas basadas en agentes;

4) el establecimiento de los requisitos técnicos y de interfaces para el sistema ATM y sus posibles sistemas sub/clientes;

5) la formulación de un plan general de desarrollo del sistema ATM, desde la concepción hasta la entrega. Este plan debe incluir directrices sobre el proceso y la planificación de la posible integración de recursos heredados, así como una evaluación de riesgos de las fases cruciales del plan. Más aún, deberá tener en cuenta la evolución actual y prevista de los recursos heredados;

6) la determinación de las estructuras de gobernación adecuadas que sustentan el desarrollo del sistema ATM, así como su funcionamiento durante toda su vida útil;

7) una evaluación de los costes totales del ciclo de vida útil ocasionados por el despliegue y explotación del sistema ATM, junto con el consiguiente plan de inversiones.

En lugar de seguir una vía secuencial, este análisis debe evolucionar de forma iterativa al objeto de determinar la estrategia óptima de despliegue del sistema. Este ciclo de estudios debe llevar, en última instancia, a obtener los siguientes resultados específicos:

— una serie completa de especificaciones técnicas, funcionales, de rendimiento y de sistemas para el suministro del sistema ATM,

— un programa de despliegue desde la concepción hasta la entrega. Éste deberá incluir la planificación detallada de todas las fases del proyecto y actividades individuales principales que lleven al cumplimiento de los objetivos finales,

— una definición de la estructura, métodos y procedimientos de gobernación (1) que sustentan el desarrollo del sistema y su validación y explotación,

— un plan de inversiones y el consiguiente proceso financiero que haga posible su realización.

7.1.3. Modalidades de ejecución

Las modalidades de aplicación de la presente ETI están sujetas a los requisitos del plan estratégico de despliegue europeo (SEDP) antes descrito.

A los efectos de la elaboración del SEDP se aplicarán los siguientes requisitos:

— las empresas ferroviarias y los administradores de las infraestructuras contribuirán con la aportación de información funcional y técnica acerca de las aplicaciones telemáticas de que disponen para los servicios de transporte de mercancías (2),

________________________________

(1) Por ejemplo, normas de aseguramiento de la calidad, metodología de desarrollo de sistemas, metodología de ensayo y planificación de la documentación.

(2) Se trata de aplicaciones telemáticas para el transporte de mercancías que ya están en servicio antes de la entrada en vigor de la presente ETI.

— los organismos representativos del sector ferroviario que operen a escala europea, de acuerdo con la definición del artículo 3, apartado 2, del Reglamento (CE) no 881/2004 formularán un plan estratégico de despliegue europeo como el descrito en el apartado anterior. Remitirán este plan estratégico a los Estados miembros y a la Comisión, a más tardar, un año después de la fecha de publicación de este Reglamento. Si tras este período de tiempo no se observan avances significativos, la Comisión Europea acometerá la tarea de proponer una norma legislativa para la puesta en práctica de la presente ETI,

— una vez finalizado el plan estratégico, todas las actividades relacionadas con la puesta en práctica del subsistema «Aplicaciones telemáticas al servicio del transporte de mercancías» deberán justificarse en virtud de este plan de despliegue. Cualquier propuesta de incumplimiento que realice una empresa ferroviaria o un administrador de infraestructura deberá justificarse en el expediente de ejecución presentado al Estado miembro, a la Agencia Ferroviaria Europea y a la CE.

7.2. Estrategia de migración

Para el período de transición entre el actual marco de sistemas de información diferenciados y el cumplimiento de la presente ETI deberán diseñarse estrategias de migración con arreglo a lo establecido en el SEDP.

Con este fin se han desarrollado los conceptos de manejo de información integrados en la presente ETI a fin de facilitar dicha migración. Estos conceptos permiten la formación progresiva del sistema paneuropeo objetivo de la ETI-ATM, en particular por medio de recursos tales como la comunicación horizontal, basada por ejemplo en el concepto de los depósitos de datos agregados (como los metadatos de mensajes, el directorio de datos y la autoridad de certificación).

A continuación se ofrece un ejemplo ilustrativo de cómo podría funcionar en la práctica esta clase de intercambio de información entre una empresa ferroviaria y un administrador de infraestructura. Este ejemplo sólo refleja las relaciones lógicas de dependencia existentes en la comunicación entre sistemas de una manera escalonada, sin tener en cuenta las necesidades de migración concretas que podrían tener los distintos sistemas. Estas últimas necesidades deben tomarse en la debida consideración en el momento de elaborar el SEDP.

Fase 1: la arquitectura general, descrita en el apartado 4.2.14.1 (Arquitectura general), incorpora el concepto de un «depósito de datos central» gestionado por una entidad neutral e independiente. En el emplazamiento de cada participante en la red de comunicaciones se especifica un nivel de interfaz para la interoperabilidad, que puede incluir un intermediario de mensajes y que puede establecerse de forma centralizada o individual. Por lo que respecta a las «redes y comunicaciones», se trata de los únicos aspectos operativos necesarios para la interoperabilidad. También son las condiciones previas básicas para el intercambio de datos a escala europea. Por lo tanto, deben realizarse e instalarse antes de que pueda entrar en servicio cualquier otra función.

Una vez realizada esta fase podrá realizarse la transmisión electrónica de documentos (apartado 4.2.13: Transmisión electrónica de documentos), sea cual sea el orden lógico que se siga en las demás fases.

TABLA OMITIDA EN PÁGINA 53

Fase 2: al mismo tiempo, o poco después de la fase 1, deben estar disponibles las bases de datos de referencia del material rodante y la base de datos de explotación de vagones y unidades intermodales (apartado 4.2.11.3:

Arquitectura general y apartado 4.2.12.2: Otras bases de datos). Si no están ya todos los datos en las bases de datos, debe ser por lo menos posible introducir manualmente en la base de datos operativa de vagones y unidades intermodales —por cada vagón de un tren en circulación— los datos necesarios para el transporte ferroviario, recogidos en el anexo A, índice 2).

TABLA OMITIDA EN PÁGINA 53

Fase 3: debe realizarse e implementarse la interfaz común de acceso externo a las distintas bases de datos, en paralelo a la fase 2 o poco después.

TABLA OMITIDA EN PÁGINA 54

En relación con las fases siguientes, es importante mencionar que la arquitectura propuesta permite una fluida puesta en servicio de las diversas funciones orientadas al cumplimiento de los requisitos del subsistema «Aplicaciones telemáticas al servicio del transporte de mercancías». Basándose en el depósito de datos central (metadatos de los mensajes, directorio y autoridad de certificación), es posible habilitar el intercambio de datos entre dos socios individualmente en función del tipo de mensaje.

Fase 4: los mensajes de solicitud de surco pueden realizarse con independencia de las fases siguientes, aunque para la fase 6 es necesario que el surco ya se identifique con un número.

TABLA OMITIDA EN PÁGINA 54

Fase 5: los datos de las solicitudes de vagones proporcionan información básica para la composición de un tren, por lo que estos mensajes deben entrar en servicio antes de la fase 6.

TABLA OMITIDA EN PÁGINA 54

Fase 6: la próxima fase es la entrada en servicio de los mensajes de preparación del tren, donde el envío del mensaje de composición del tren es el más importante y debe ser el primero en realizarse.

TABLA OMITIDA EN PÁGINA 55

Fase 7: a más tardar antes de la fase 8, deberán realizarse, a nivel de EF, las funciones de movimiento de vagones «Aviso de liberación del vagón», «Aviso de salida del vagón», «Llegada al depósito de vagones», «Salida del depósito de vagones», «Aviso de llegada del vagón» y «Aviso/confirmación de entrega del vagón en destino», junto con la funcionalidad de planificación de trayectos.

TABLA OMITIDA EN PÁGINA 55

Fase 8: para la próxima fase deberán realizarse los mensajes «Tren en circulación» y «Previsión de circulación del tren». Con el mensaje de previsión de circulación del tren podrá enviarse la hora prevista de llegada del tren (ETA-T o ETH), que sirve de base para el cálculo de las ETI y de la ETA del vagón o expedición. Esta fase también incluye la realización de la consulta/respuesta relativa al tren en circulación y a la previsión del tren.

TABLA OMITIDA EN PÁGINA 55

Fase 9: los avisos de intercambio (apartado 4.2.9: Avisos de intercambio) y la funcionalidad del apartado 4.2.7 [Hora prevista de intercambio (ETI)/Hora prevista de llegada (ETA) de un envío] deberán ponerse en práctica al mismo tiempo que la fase 8 o poco después. Esto se aplica especialmente a las EF.

TABLA OMITIDA EN PÁGINA 56

Fase 10: la realización de la funcionalidad de «información sobre trastornos del servicio» forma parte de la fase 10, junto con la realización de la consulta/respuesta sobre retrasos del tren, el identificador del tren y el tren en el lugar de notificación. Basándose en la información de trastornos podría entrar en servicio el mensaje de excepción de vagones para la EF (apartado 4.2.8.6: Mensaje de excepción del vagón y apartado 4.2.8.7: Mensaje de excepción del vagón, solicitud nueva ETI/ETA).

TABLA OMITIDA EN PÁGINA 56

Fase 11: tras una fase de consolidación, podría entrar en servicio la evaluación de los datos transmitidos y almacenados para mejorar la calidad.

TABLA OMITIDA EN PÁGINA 56

7.3. Gestión de cambios

7.3.1. Introducción

El cambio es una faceta inherente a cualquiera de los sistemas informáticos que se utilizan en los entornos reales.

Es impulsado por la aparición de nuevas necesidades o por variaciones de las necesidades ya existentes, bien por errores observados en la explotación, bien por la necesidad de mejorar las prestaciones u otras características no funcionales.

Pero es preciso gestionar el cambio, ya que se sustenta en la continuidad de las consideraciones de servicio y en objetivos de retrocompatibilidad, a fin de reducir al mínimo los gastos generales, tanto en tiempo como en dinero, que conlleva la explotación de los equipos informáticos ya desplegados que prestan la funcionalidad ATM (es decir, recursos informáticos heredados). Por lo tanto, es crucial definir una estrategia clara para aplicar y gestionar los cambios en los equipos informáticos heredados, a fin de evitar trastornos de las operaciones ferroviarias sin socavar los objetivos subyacentes de garantizar la continuidad del servicio y la interoperabilidad.

La definición de una estrategia de este tipo se basa en dos cuestiones principales:

— la creación de un marco de administración de configuraciones que defina las normas y procedimientos para gestionar la evolución del sistema. Esto debe incluir la forma de registrar y procesar los cambios propuestos en el sistema, la forma de relacionar estos cambios con los componentes del sistema y la forma de realizar el control de revisiones del sistema,

— una política de revisiones de estados básicos del sistema.

7.3.2. Determinación de estados básicos

La estabilidad del sistema es esencial para que la implantación y el despliegue efectivos puedan ser realistas. Esta necesidad de estabilidad es parecida para todas las partes:

— los administradores de infraestructuras y las empresas ferroviarias, que tendrán que manejar varias versiones de los sistemas que prestan funcionalidad ATM;

— el sector, que necesita tiempo para especificar, desarrollar y demostrar una interoperabilidad permanente.

Un estado básico, en esencia, incorpora el concepto de un núcleo estable en términos de funcionalidad del sistema, prestaciones y otras características no funcionales (por ejemplo, la memoria RAM) (1). Sin embargo, la experiencia anterior con este tipo de sistemas demuestra que hacen falta varias revisiones de una versión (2) a fin de conseguir un estado básico estable y adecuado para la implantación. Esto puede ilustrarse con el siguiente proceso en cascada:

IMAGEN OMITIDA EN PÁGINA 57

Este proceso está muy entrelazado, gracias a sus circuitos de realimentación. Esto impide poner varios de estos procesos en paralelo, un enfoque que conduciría a situaciones de inestabilidad, confusión y problemas de explotación. Por lo tanto, los estados básicos deben ser procesados en serie, como se ilustra a continuación:

IMAGEN OMITIDA EN PÁGINA 57

____________________________

(1) Un estado básico sirve de punto de partida de referencia en la gestión controlada de la evolución del sistema.

(2) Una revisión es la versión del sistema que se distribuye a los clientes ferroviarios. Las versiones del sistema pueden tener distinta funcionalidad o prestaciones o pueden reparar averías del sistema o corregir deficiencias de seguridad.

7.3.3. Revisión de un estado básico

De acuerdo con la experiencia actual, el período de tiempo que transcurre entre distintos estados básicos suele ser de cuatro o cinco años.

La determinación de un nuevo estado básico debe vincularse, en principio, con la aplicación de modificaciones significativas en la funcionalidad o prestaciones del sistema, que pueden afectar a aspectos tales como:

— la incorporación de un conjunto de funciones nacionales actuales, que pueden ser objeto de generalización en el núcleo interoperable,

— otros servicios futuros de valor añadido.

Cada estado básico debe además incorporar la funcionalidad del estado básico anterior. La depuración de versiones para reparar fallos del sistema o corregir deficiencias de seguridad debe tratarse como una revisión de una versión de un determinado estado básico. A menos que sea imposible por razones de seguridad, estas revisiones de las versiones de un mismo estado básico deberán ser retrocompatibles.

La funcionalidad añadida que podrían incorporar los distintos estados básicos implica necesariamente que no hay retrocompatibilidad entre estados básicos. Sin embargo, a fin de facilitar la migración, y siempre que sea posible desde el punto de vista técnico, los distintos estados básicos deben incorporar un núcleo común de funcionalidad cuya retrocompatibilidad debe estar garantizada. Este núcleo común debe habilitar la prestación de servicios de datos interoperables con prestaciones aceptables.

7.3.4. Despliegue de nuevos estados básicos

Los administradores de infraestructuras y las empresas ferroviarias nunca van a estar en situación de pasar de un estado básico al siguiente de la noche a la mañana. Por lo tanto, cada estado básico deberá desarrollarse con una estrategia de migración apropiada. El objetivo es resolver problemas tales como la coexistencia de recursos ATM conformes con distintas versiones de las especificaciones ATM, vías de migración preferentes (concretamente, prioridad de la vía, prioridad del material rodante, o simultaneidad), así como los plazos de tiempo orientativos y prioridades de la migración.

7.3.5. Proceso de gestión de cambios: requisitos

Como ya se ha dicho, el cambio es un hecho inevitable para los grandes sistemas de software. Por lo tanto, es preciso diseñar procedimientos de gestión de cambios a fin de asegurar que los costes y beneficios del cambio se analicen debidamente y que los cambios se apliquen de forma controlada. Para ello es necesario que el proceso de gestión de cambios que se defina y las herramientas asociadas garanticen que los cambios se registren y se apliquen a las especificaciones de manera rentable. Cualesquiera que puedan ser los aspectos concretos del proceso, esto último debe planificarse con carácter general a través de un enfoque estructurado, de la forma siguiente:

IMAGEN OMITIDA EN PÁGINA 58

El proceso de gestión de cambios anteriormente descrito debe sustentarse en un plan de administración de configuraciones que incorpore el conjunto de normas y procedimientos de gestión de cambios. Los requisitos genéricos aplicables a un plan de esta índole se describen el apartado 7.3.6. La estrategia de aplicación de los cambios aprobados deberá formalizarse (en virtud del correspondiente proceso y documentación) en un plan de gestión de cambios que incluya, en particular:

— la determinación de las limitaciones técnicas que justifican el cambio,

— una declaración de quién asume la responsabilidad de los procedimientos de aplicación de los cambios,

— el procedimiento de validación de los cambios que se vayan a aplicar,

— la política de gestión de cambios, revisión de versiones, migración y despliegue.

Una parte importante del proceso de gestión de cambios es la definición de las responsabilidades relativas a la entrega de las especificaciones y a los procesos de aseguramiento de la calidad y administración de configuraciones. Está previsto que la mayor parte de estas tareas pasen a la Agencia Ferroviaria Europea [constituida por el Reglamento (CE) no 881/2004], o se sometan a su supervisión, cuando este proceso comience a funcionar. El proceso de gestión de cambios deberá formalizarse en el paquete de documentación señalado en el anexo A.

Por último, es esencial que el Comité de control de cambios (Change Control Board, CCB), que actuará como autoridad competente en todos los aspectos del sistema, esté formado por una representación de todas las partes interesadas, concretamente los administradores de las infraestructuras, las empresas ferroviarias, el sector de suministros, los organismos notificados y las autoridades reguladoras por igual. Esta filiación de las partes debe garantizar una perspectiva de sistema sobre los cambios que vayan a realizarse y una evaluación global de sus implicaciones. El CCB estará en última instancia bajo la tutela de la Agencia Ferroviaria Europea.

7.3.6. Plan de administración de configuraciones: requisitos

El plan de administración de configuraciones deberá describir el conjunto de normas y procedimientos aplicables a la gestión de cambios y comprender, en particular:

— la definición de las entidades que deberán gestionarse y un esquema formal para su identificación,

— una declaración de quién asume la responsabilidad de los procedimientos de administración de configuraciones y del sometimiento de las entidades controladas a la estructura decisoria de la administración de configuraciones,

— las políticas de administración de configuraciones que vayan a utilizarse para el control de cambios y la administración de versiones,

— una descripción de los registros que deberán mantenerse a lo largo del proceso de administración de configuraciones,

— una descripción de las herramientas que deberán utilizarse en la administración de configuraciones y el proceso que se aplicará para utilizar dichas herramientas,

— una definición de la base de datos de configuraciones que se utilizará para registrar la información de las configuraciones.

Los aspectos específicos de los procesos de administración de configuraciones deberán formalizarse a través de especificaciones que serán incorporadas a la lista incluida en el anexo A de la presente ETI.

7.4. Casos específicos

7.4.1. Introducción

Se autorizan las siguientes disposiciones particulares en los siguientes casos específicos.

Estos casos específicos pertenecen a dos categorías: las disposiciones se aplican de forma permanente (caso «P») o temporal (caso «T»). En los casos temporales, se recomienda que los Estados miembros afectados se ajusten al subsistema pertinente en 2010 (caso «T1»), que es el objetivo establecido en la Decisión no 1692/96/CE del Parlamento Europeo y del Consejo, de 23 de julio de 1996, sobre orientaciones comunitarias para el desarrollo de la red transeuropea de transporte (1), o en 2020 (caso «T2»). «T abierto» se define como un período indeterminado, que se fijará en una futura revisión de la presente ETI.

_______________________________

(1) DO L 228 de 9.9.1996, p. 1. Decisión modificada en último lugar por la Decisión no 884/2004/CE (DO L 167 de 30.4.2004, p. 1). Decisión corregida en el DO L 201 de 7.6.2004, p. 1.

7.4.2. Lista de casos específicos

7.4.2.1. Caso específico de los Estados miembros de la UE fronterizos con terceros países

En los territorios de los Estados miembros de la UE que tienen frontera con terceros países, los requisitos de la presente ETI no serán obligatorios para los transportes con origen o llegada directa en estos terceros países (caso «T abierto»).

Sin embargo, si el trayecto de transporte se prolonga a otro Estado miembro de la UE los requisitos de la presente ETI deberán aplicarse en su totalidad, siempre que no exista un acuerdo bilateral o multilateral entre los Estados afectados o entre empresas ferroviarias o administradores de infraestructuras que actúen en el territorio de dichos Estados miembros.

7.4.2.2. Caso específico de Grecia

En los transportes que operen en líneas de 1 000 mm de ancho de vía se aplicará la normativa nacional.

ANEXO A

LISTA DE DOCUMENTOS COMPLEMENTARIOS

Lista de especificaciones obligatorias

TABLA OMITIDA EN PÁGINA 61

ANEXO B

GLOSARIO

TABLA OMITIDA EN PÁGINAS 62 A 72