Resumen

El impulso de la Unión Europea para la aplicación de la infraestructura europea de satélites de navegación GALILEO en áreas específicas, como el transporte, se ha visto reflejado en el creciente desarrollo de productos y proyectos de cobertura mundial que se benefician de sus prestaciones, calidad de los servicios y, al tratarse de la única opción GNSS en el mundo bajo control civil, de su fiabilidad y disponibilidad. El Laboratorio de Interoperabilidad Ferroviaria (LIF) del CEDEX, consciente del potencial de estos nuevos desarrollos en la señalización ferroviaria europea ERTMS, participa activamente en los proyectos EGNSS europeos, y prepara su laboratorio para afrontar los nuevos desafíos. En este artículo se describe la experimentación realizada en el laboratorio ERTMS-GNSS del CEDEX dentro del proyecto GATE4Rail, destacando el papel que los laboratorios ERTMS tienen actualmente en la puesta en servicio de las líneas ERTMS y señalando el camino para las líneas futuras donde el uso de satélites será cada vez más relevante.

1. INTRODUCCIÓN

El proyecto GATE4Rail ( GNSS Automated Virtualized Test Enviroment for Rail ), con una duración de 2 años y finalizado en febrero de 2021, se engloba dentro del desafío europeo de “Transporte inteligente, ecológico e integrado”. Ha sido financiado por el programa Shift2Rail, en el marco del Programa de Innovación 2 (IP2) sobre señalización, posicionamiento seguro y sistemas avanzados de control y gestión de tráfico (Grant Agreement 826324).

El proyecto cuenta con la participación de socios de distintos países: RadioLabs, RFI y Bureau Veritas (Italia), Universidad Gustav Eiffel y GUIDE (Francia), UNIFE y M3S (Bélgica), INECO y CEDEX (España).

Como se muestra en el presente artículo, GATE4Rail es un proyecto eminentemente experimental, teniendo por objetivo la definición de una estructura de interconexión entre centros de referencia europeos de GNSS y el Laboratorio de Interoperabilidad Ferroviaria (LIF), del CEDEX, especializado en señalización ERTMS, permitiendo ensayar y analizar el impacto de la tecnología GNSS en el sistema ERTMS

Más concretamente, el proyecto se ha centrado en evaluar la incorporación en el sistema ETCS embarcado de un nuevo módulo de posicionamiento basado en el uso de balizas virtuales, tal y como puede verse en la figura 1.1. De esta manera es posible reducir el equipamiento de vía y, por tanto, el coste de implementación del ERTMS.

Figura 1.1. ETCS con módulo GNSS embarcado.

En todo caso, el entorno de pruebas diseñado permite evaluar no solo el uso de balizas virtuales, sino cualquier otra implementación que fusione ERTMS con GNSS, como por ejemplo la función de odometría mejorada, entre otras.

Las herramientas desarrolladas dentro del proyecto permiten generar y simular una serie de efectos globales y locales de GNSS en determinadas zonas y combinarlas con diferentes disposiciones de balizas virtuales, para observar y analizar el efecto en las circulaciones de los trenes. Por otro lado, es posible realizar ensayos simulando diferentes fechas y horarios y, por tanto, con diferentes posiciones de los satélites GPS y Galileo en sus orbitas, con el fin de evaluar otros aspectos como la fiabilidad o la disponibilidad de la solución implementada.

Una premisa fundamental en todos los ensayos en laboratorio es la exactitud de la posición del tren en la vía, tanto desde un punto de vista estático como dinámico. La definición de este perfil dinámico, compuesto por una marca de tiempo (fecha y hora), junto con la posición precisa del punto de referencia del tren, en coordenadas geográficas y a lo largo de la vía (punto kilométrico), permite evaluar la bondad de la solución GNSS implementada y, por tanto, su idoneidad para el uso. Esta evaluación se basa en la comparación entre la posición teórica en un momento dado, con la posición obtenida por los módulos GNSS. Este mecanismo tan simple puede usarse para una evaluación a nivel de componente, de subsistema o incluso de sistema, por lo que se destaca como un elemento fundamental para el desarrollo y validación de la integración de esta tecnología GNSS en el ERTMS.

Este artículo se centra en una descripción de los desarrollos del CEDEX en las diferentes secciones del proceso, desde la creación de una base de datos para las líneas que incluyan las coordenadas geográficas, hasta los desarrollos que permiten la carga, ejecución y análisis automático de las circulaciones bajo diferentes condiciones de pruebas sobre la ruta seleccionada, mostrando las capacidades y posibilidades que el LIF puede ofrecer.

Finalmente cabe destacar que en la página web del proyecto [1] hay disponible información adicional sobre el proyecto y la plataforma desarrollada.

2. ARQUITECTURA DE LA INFRAESTRUCTURA DE LOS LABORATORIOS Y DESARROLLO DEL PROCESO

Una tarea crucial del proyecto ha sido la definición de la arquitectura de la plataforma de ensayos geo-distribuida entre los laboratorios de los diferentes socios. La interconexión entre los laboratorios se define creando unos módulos y unas interfaces que permiten el flujo de datos entre ellos tal y como se observa en la figura 2.1.

Figura 2.1. Arquitectura de la infraestructura de Laboratorios [1].

El proceso de simulación comienza en el módulo#2-CEDEX mediante la creación de los datos correspondiente a la ruta que se va a ensayar conteniendo la trayectoria, el perfil de velocidades, las condiciones de ensayo de GNSS y el diseño de vía con balizas virtuales. De este modo se crea la base de datos en 1D-3D de la línea y el perfil dinámico de velocidad, generando la localización geodésica de la antena del tren (PVT0) en cada coordenada temporal y espacial a lo largo de la vía.

En sentido de las agujas de reloj, el módulo#2-INECO genera para cada coordenada los datos correspondientes a la visibilidad de satélites considerando las características del terreno de los modelos del Instituto Geográfico Nacional teniendo en cuenta la fecha y hora elegida de circulación y los obstáculos locales (arboleda, pasos elevados, túneles, trinchera...) a lo largo de la trayectoria.

El módulo#3-UGE-GUIDE-M3S recibe el perfil dinámico de velocidad, los obstáculos locales, la visibilidad de satélites y las condiciones de ensayo GNSS. A continuación, evalúa la distorsión debida a los obstáculos que encontrará el tren en su trayectoria y finalmente, genera los datos de navegación que recibiría una antena GNSS situada en el techo del tren al recorrer esa ruta a dicha velocidad y en esa fecha. Por otro lado, se pueden introducir otros efectos locales (EMI, jamming y/o spoofing ) y globales GNSS (fenómenos en la ionosfera, fallo de reloj en los satélites, etc.), así como medidas correctivas basadas en los diversos sistemas de aumentación susceptibles de emplearse en dicha trayectoria. De forma adicional, una vez finalizada la generación de los datos de navegación, es posible calcular una primera solución PVT1 (posición-velocidad-tiempo) para un receptor GNSS tipo para la localización del tren.

El módulo#4-RadioLabs recibe por una parte los datos de navegación de satélite GNSS del módulo#3, y por otra parte las coordenadas geográficas referencia de la vía del módulo#2-CEDEX. Con esta información, el módulo#4 restringe el movimiento a la vía, y calcula una segunda estimación de la posición del tren (segunda solución PVT2) y su incertidumbre asociada en la vía ( Protection Level )

El módulo#5-Radiolabs, con la información recibida del módulo#2 CEDEX del listado de balizas virtuales en vía con su localización geográfica, y con la posición de la antena junto con su incertidumbre en cada instante, obtenida del módulo#4 de navegación, calcula el instante de disparo al paso por las balizas virtuales, y define la incertidumbre asociada.

El proceso termina en el módulo#1-CEDEX. En este módulo se generan de forma automática los ficheros de datos a cargar en los simuladores del LIF, esto es, la ruta, el perfil de velocidad, los disparos de balizas y su incertidumbre (acorde a la información recibida del módulo#5). Tras la ejecución del escenario, se almacenan de forma ordenada los registros de laboratorio (velocidad, eventos en el interfaz con el tren, disparos de balizas, etc.), la grabación del DMI ( Driver Machine Interface ) con la información que ve en cabina el maquinista y el registro de JRU ( Juridical Recorder Unit ) de la Eurocabina. Los desarrollos de análisis automático permiten generar el resultado en un informe final de la prueba. El diagrama de flujo de la figura 2.2 resume el proceso.

Figura 2.2. Diagrama de flujo del proceso.

3. GENERACIÓN DE DATOS DE LA LÍNEA ESPAÑOLA

La base de datos utiliza una estructura creada a partir del Subset-112 ( UNISIG Basics for Interoperability Test Scenario Specifications ), que consiste en:

  • Topología de la línea: basada en listas de toperas, conectores, desvíos y segmentos de vía.
  • Elementos de vía: basada en una lista de balizas y de señales.
  • Rutas posibles: con la lista de segmentos y sentido, la lista de balizas y señales con los telegramas y aspectos específicos para cada ruta.

Sobre esta estructura de datos, con una localización basada en puntos kilométricos, se ha añadido una capa de información con las coordenadas geodésicas (latitud, longitud, altura):

  • Mapa de segmentos: basada en una lista de coordenadas geográficas de todos los puntos dentro de un segmento con una resolución de un metro, indicando la distancia relativa al origen del segmento y su PK asociado, junto con información adicional de elementos de la infraestructura.

Con el fin de garantizar un solapamiento correcto entre la estructura de datos inicial (basada en longitudes a lo largo de la vía) y el esquema basado en coordenadas geográficas (basado en longitud, latitud y altura), se hizo especial hincapié en preservar las distancias recorridas en las dos representaciones. De esta manera, se partió de las medidas recogidas en el terreno sobre las que se aplicó un algoritmo propio para obtener un promedio de los recorridos por cada sección de la línea, promedio que se tomó como mejor valor representativo de las coordenadas, como puede observarse en la figura 3.2, y que se ajusta a la tira de vía de la figura 3.3.

Figura 3.1. Línea de Almorchón-Alhondiguilla, mapa de segmentos en coordenadas geodésicas (imagen de la derecha visualizada en Google Maps).

Figura 3.2. Estación de Almorchón (Fuente: Google Maps).

Figura 3.3. Plano esquemático de la línea en una dimensión [1].

Figura 3.4. Referencia relativa al morro del tren.

Figura 3.5. Plano de señalización.

En relación a los parámetros de posicionamiento de las antenas con respecto al resto de elementos se considera en las pruebas que, la posición de las antenas BTM ( Balise Transmission Module ) y GNSS con respecto a los ejes transversal y longitudinal del tren es la misma, siendo su altura con respecto al rail la que varía.

En cuanto al tramo en estudio, el presente artículo se centra en la línea de Almorchón-Mirabueno, sobre la que se aplicó una ingeniería de vía ERTMS definida íntegramente por el CEDEX y que contempla: funcionalidades ERTMS, requisitos de infraestructura para la localización de señales luminosas/virtuales y localización de balizas físicas/virtuales.

El diseño de la ingeniería de vía se ha realizado ad-hoc para los fines específicos del proyecto. De hecho, en otros tramos de la línea española se han planteado ingenierías dispares con el fin de estudiar otras casuísticas de la integración GNSS-ERTMS, tal y como se indica en el apartado 4.

Además, aparte de la señalización, sobre cada punto de la vía con resolución de un metro se indican la coordenada y la característica que aplique de la infraestructura de la propia vía o del entorno que tenga impacto en la recepción de señales GNSS, por ejemplo, una estación techada, una trinchera, una zona arbolada o el caso de un puente con estructura metálica. Para clasificar los distintos efectos locales en la señal GNSS se ha definido una tabla con los identificadores asociados a cada una de las características que pueden encontrarse en la vía.

Figura 3.6. Clasificación de interés de tramos de la vía realizada por el CEDEX.

Nota: cabe destacar que en el apartado de simulación de GATE4RAIL se han considerado únicamente en aquellos fenómenos con afectación en la señal GNSS.

Figura 3.7. Marcado de la infraestructura, puente ‘Juana la Mala’ en la línea de Almorchón (Fuente: Google Maps).

Con esta información previa se completan las siguientes estructuras que forman parte de las bases de datos: Topología:

  • Segments (id, lineid, connector1, connector2, length, latmax, latmin, lonmax, Lonmin ,hmax, hmin)
  • Connectors (id, lineid, connection1, connection2, kp1, kp2, latitude, longitude, height, mileage)
  • Points (id, lineid, connection1, connection2, connection3)
  • Ends (id, lineid, connection)

Elementos de vía:

  • Balises (id, direction, segment, offset, idtel, coded telegram, latitude, longitude, height)
  • Signals (id, direction, segment, offset, description, code, latitude, longitude, height )

Mapas de la vía ( Trackmaps ):

  • Segments (id, distance, latitude, longitude, height, mileage, local, detail)

Rutas:

  • Routes (id, description, direction, list of segments, list of balises, list of signals)

4. CASOS DE PRUEBAS

Una vez generada y estructurada la información del apartado anterior, es necesario distribuir los diversos casos de prueba a lo largo de la vía, allí donde apliquen o se quiera estudiar alguna interacción especial entre la aplicación ERTMS de posicionamiento basado en balizas virtuales y la localización GNSS.

En la primera fase del proyecto se han definido un conjunto de casos de prueba genéricos 1 de GNSS y de ERTMS que aplican al uso de balizas virtuales (VB) y su detección por un Virtual Balise Reader a bordo (VBR). En la figura 4.1 se muestra un ejemplo de lista de casos de pruebas [1].

Figura 4.1. Conjunto de casos de pruebas ERTMS y GNSS.

Estos casos de prueba se aplicarán de manera distinta dependiendo del caso de uso específico. En el proyecto GATE4Rail, la campaña de ensayos se ha centrado en dos tipos de líneas donde la implementación de la baliza virtual tiene mayor proyección:

  • Línea de Cercanías en operación en Cerdeña (Italia), utilizada como línea piloto en Italia y sobre la que se han realizado pruebas con balizas virtuales. En este caso, los ensayos realizados corresponderían al caso de uso de la validación de una línea real en funcionamiento con balizas virtuales.
  • Línea regional de bajo tráfico en Almorchón (España), en el que se ha diseñado en el marco del proyecto una ingeniería de vía ERTMS con balizas virtuales. Este sería el caso de uso para el diseño de una nueva línea con ERTMS y balizas virtuales.

Sobre estas líneas se han creado diferentes escenarios, combinando diferentes casos de pruebas de ERTMS con casos de pruebas de GNSS. Con el objetivo de simplificar, de entre los casos de pruebas definidos en el proyecto se han utilizado los siguientes:

  • Casos de prueba ERTMS: grupos de balizas simples y múltiples.
  • Casos de prueba GNSS: cielo abierto, fallo del reloj de satélite, efectos en la ionosfera, interferencias electromagnéticas y áreas restringidas por efectos locales (arboleda, zona urbana, túnel y pasos elevados).

En el artículo se elige un escenario de la línea española de los ejecutados en la campaña de pruebas para mostrar todo el proceso.

5. CONCEPTO DE ESCENARIO Y SIMULACIÓN

Los datos de las líneas y los casos de prueba son sólo una parte preliminar del proceso de ensayo. Hay una serie de pasos adicionales que es necesario dar antes de proceder a la distribución de datos entre los distintos módulos de la arquitectura y ejecutar los distintos cálculos de forma ordenada, siguiendo el proceso descrito en el apartado 2. Estos pasos adicionales son la construcción de escenarios y la definición de simulaciones.

Así, el escenario queda definido como una selección de casos de prueba específicos (tanto GNSS como ERTMS) localizados en puntos concretos del tramo de vía a estudiar. La localización de los casos de prueba es un punto clave ya que para evaluar la interacción entre la casuística GNSS y la ERTMS es necesaria una coincidencia espacio-temporal. Así, para estudiar el efecto de determinados obstáculos en la localización satelital en escenarios con una nueva ingeniería de vía, se han posicionado balizas virtuales en las cercanías de dicho obstáculo.

Por otro lado, desde el punto de vista operacional, todo ensayo ERTMS debe constar de un punto de arranque del tren, de un inicio de misión ERTMS, de una circulación por un tramo de vía significativo en un modo ERTMS en el que se supervise el paso por las balizas virtuales y, finalmente, de una parada del tren. Además, en estos escenarios existe una comunicación tren-vía constante a lo largo de la simulación.

Conjugando los dos conceptos anteriores se llega a una nueva entidad que, dentro del proyecto GATE4Rail, se ha denominado simulación y que viene a ser un ensayo operacional ERTMS completo en el que la dinámica del tren a lo largo de la simulación queda prefijada en cuanto a fecha, hora, posición y velocidad del tren. En este punto cabe destacar que el concepto de simulación incluye cualquier perturbación GNSS (real o intencionada) que se quiera introducir en el ensayo.

Como puede verse en la figura 5.1, dada la diversidad de situaciones que pueden aparecer durante una simulación, es posible evaluar varios escenarios distintos en un solo ensayo, lo que finalmente redunda en una mayor eficiencia de las pruebas. En el proyecto GATE4Rail se definieron siete simulaciones dentro del grupo de trabajo WP4, dedicado a la demostración de la funcionalidad de la arquitectura. En este artículo se muestra la simulación #3, con las siguientes características:

  • Recorrido BA_R5: tramo de la línea española, entre Espiel y Alhondiguilla de unos 5.500 metros.
  • Ingeniería de vía ERTMS nominal, diseñada por CEDEX, con una distribución de grupos de balizas virtuales simples y dobles.
  • Perfil de velocidad con unas aceleraciones para la tracción y freno, junto con la fecha y hora de arranque y un retardo para iniciar el movimiento.
  • Condiciones nominales de satélites de posicionamiento (cielo abierto) hasta el segundo 240 (a partir de 3.600 metros, aproximadamente), en el que se introduce un fallo de reloj en los satélites GPS hasta el final de la simulación.
  • La zona de perturbación GNSS afecta a cuatro grupos simples de balizas virtuales y a dos grupos dobles. De esta manera, es posible cubrir cuatro escenarios:
  • Dos escenarios en condiciones GNSS nominales (caso de prueba GNSS G4R_GNSS_GTC_1) con grupos de balizas simples (caso de prueba ERTMS G4R_ERTMS_GTC_1) y dobles (caso de prueba G4R_ERTMS_GTC_2) en condiciones de cielo.
  • Dos escenarios en condiciones de fallo de reloj de satélite (caso de prueba GNSS G4R_GNSS_GTC_7) con grupos de balizas simples (caso de prueba ERTMS G4R_ERTMS_GTC_1) y dobles (caso de prueba G4R_ERTMS_GTC_2) en condiciones de cielo.

Figura 5.1. Concepto de escenario [1].

6. COMIENZO DEL PROCESO (MÓDULO#2-CEDEX)

Con la información definida en el apartado anterior, se generan los siguientes datos requeridos por los otros laboratorios externos al CEDEX ( módulo#2-INECO, módulo#3-UGE-GUIDE-M3S, módulo#4-RDL, módulo#5-RDL ):

  • El Static Ground Truth corresponde a los datos del recorrido de la vía (con precisión de metro) con una correspondencia entre la distancia al origen de partida, el PK y las coordenadas geodésicas referidas a tope del rail y centradas en la traviesa.
  • El Route Balise Location es un listado de las balizas del recorrido, con su identificador, localización en la sección de la vía, coordenadas geodésicas, información trasmitida y un código indicando si es virtual o real.
  • El Dynamic Ground Truth corresponde al movimiento del tren con referencia al morro, esto es, referido al tiempo con una resolución de 0.1 segundos. Se proporcionan las coordenadas geodésicas, la distancia al origen y la velocidad. Adicionalmente se genera la información en los formatos requeridos por otros módulos referidos a la posición de la antena GNSS en el tren.

En las siguientes figuras se muestran los resultados de estas operaciones.

Figura 6.1. Static Ground Truth, balizas del escenario, perfil de alturas y de velocidad en función de la distancia [1].

Figura 6.2. Dynamic Ground Truth, perfiles de velocidad, aceleración y distancia recorrida en función del tiempo [1].

Cada archivo del módulo#2-CEDEX incluye una la plantilla de datos referencia con el objetivo de garantizar la trazabilidad íntegra a lo largo de todo el proceso de simulación, tal y como se observa en la figura 6.3:

Figura 6.3. Cabecera de datos de referencia del Dynamic Ground Truth.

7. ÚLTIMA ETAPA DEL PROCESO (MÓDULO#1-CEDEX), EJECUCIÓN DE LAS SIMULACIONES ERTMS

Una vez realizada la simulación en los laboratorios de GNSS, acorde a lo descrito en el apartado 2, se procede a describir los desarrollos y acciones en el módulo#1-CEDEX para llevar a cabo la fase de simulación ERTMS.

En los casos que nos ocupan, se evalúa la función ERTMS de posicionamiento del tren y comprobación de la información de enlace. Mediante esta función, el equipo ETCS verifica que pasa por una serie de balizas que previamente le han notificado y que la distancia recorrida entre esos grupos de balizas está dentro de unos márgenes respecto a las separaciones teóricas indicadas en la información de enlace entre balizas. Este mecanismo ERTMS permite al tren conocer el camino a recorrer, su longitud y reaccionar de forma segura ante cualquier desviación que pueda suceder. La novedad del proyecto GATE4Rail consiste en sustituir las eurobalizas instaladas en las vías por balizas virtuales, cuyas posiciones se fijan sobre un mapa. La localización de las mismas a bordo depende de los sistemas de posicionamiento por satélite y, por tanto, puede variar dependiendo de las circunstancias. Para evaluar la bondad de esta aproximación, se comprueba si la variación en la localización de las balizas virtuales entra dentro de los márgenes permitidos por la función ERTMS de comprobación de la información de enlace y, por tanto, no produce ninguna reacción de seguridad por parte del tren.

Dado que en la actualidad no existen equipos industriales embarcados de localización de balizas virtuales (denominado Virtual Balise Reader), dentro del proyecto GATE4Rail se ha ideado un método, analizado por un desarrollo de simulación off-line, para poder verificar el impacto de las balizas virtuales en las funciones de posicionamiento ERTMS implementadas en una eurocabina industrial. Los pasos son los siguientes:

  • Las balizas virtuales se sustituyen por balizas reales.
  • Estas balizas se disparan en el tiempo y la posición indicados por el módulo#5-RDL.
  • La eurocabina es informada previamente de las posiciones teóricas de las balizas.
  • La eurocabina es informada previamente del margen de precisión en la localización de dichas balizas, extraído del intervalo de confianza calculado por el propio módulo#5-RDL.
  • Se deshabilita la reacción de frenado en caso de fallo en la localización de las balizas para que no haya distorsión en la velocidad del tren, aunque los errores quedan registrados para su posterior evaluación.

Este proceso debe integrarse en la definición del ensayo, que, como ya se ha indicado anteriormente, debe tener significancia operacional. Por ello, todos los ensayos (o simulaciones, siguiendo la nomenclatura introducida en secciones anteriores) consisten en un encendido del tren, en parado, en un momento y localización determinados. El maquinista hace un procedimiento ETCS de Inicio de Misión, que consiste en la introducción de ciertos datos y en el establecimiento de comunicaciones con los equipos de vía (en este caso, simulados). Una vez finalizado el proceso, transcurrido un tiempo pre-programado, el tren empieza a moverse y lee dos de balizas para localizarse. En ese momento, se informa a la vía, que contesta a su vez con una descripción detallada del recorrido por delante del tren, incluida la información de enlace. Al recibir esa información, el tren entra en un modo denominado Supervisión Total, que activa la función ERTMS mencionada anteriormente de localización del tren y comprobación de la información de enlace de baliza. A partir de este momento, el tren continúa su recorrido, leyendo las balizas en las posiciones calculadas por el módulo#5-RDL . Dicho recorrido se realiza a velocidad constante. Finalmente, el tren desacelera y se detiene.

Previamente a la ejecución sistemática de las simulaciones se ha preparado el laboratorio, caracterizando la línea, el tren y las conexiones necesarias, abordando los siguientes puntos:

  • Datos de la línea:
  • Posición del tren y recorrido, gradiente, electrificación.
  • Localización de disparo teórico de balizas con sus telegramas.
  • Perfil de velocidad.
  • Datos del tren:
  • Masa, longitud, distancia antena BTM al morro y comportamiento dinámico.
  • Datos del RBC simulado:
  • Mensajes de comunicaciones de radio vía-tren.
  • Conexión de una Eurocabina real.
  • Mensajes de balizas.
  • Conexión de las señales de TIU ( Train Interface Unit ).
  • Conexión de la odometría.

Posteriormente se genera la base de datos requerida para la carga y ejecución en los propios simuladores ERTMS del LIF ( módulo#1-CEDEX ). De cara a la ejecución del ensayo se han tenido en cuenta no solo los datos del módulos#2-CEDEX sino los proporcionados por el módulo#5-RDL, esto es, los instantes de disparo de la balizas virtuales y su incertidumbre, disparos que dependerán de la respuesta a las entradas generadas en los laboratorios GNSS incluyendo los efectos globales y locales según los casos de prueba GNSS seleccionados.

El LIF desarrolló en el marco del proyecto una herramienta que establece la relación directa entre los instantes de disparo del módulo#5-RDL y la distancia recorrida, de modo que las plantillas de balizas ERTMS se actualizan automáticamente a las nuevas posiciones dadas por el generador de balizas virtuales (módulo#5). Cabe destacar que la información de enlace almacenada en los telegramas de balizas que dan la autorización de movimiento mantiene el valor de distancia teórica entre grupos de balizas y actualiza la nueva incertidumbre en la variable Q_LOCACC .

Por parte del Laboratorio de Eurocabina, éste dispone de herramientas de visualización de las bases de datos con toda la información programada para la ejecución de un escenario.

En el apartado de visualización y análisis de escenarios, se han desarrollado herramientas para la automatización de todo el proceso, desde la visualización en 3D, pasando por el almacenamiento de datos (grabación de DMI, registros de JRU y módulos del laboratorio), hasta el análisis y obtención de la hoja de resultados finales.

De esta forma, durante la ejecución de un ensayo, además del comportamiento del tren y los disparos de balizas en el plano 1D y el DMI, se visualiza también en el plano 3D (a través del visualizador Google Earth) la información del campo en tiempo real: esto incluye la información estática del plano de vías con la localización teórica de las balizas, la posición real del tren, las posiciones de disparo de las balizas (módulo#5-RDL), la solución de posición de un receptor GNSS comercial (módulo#3-M3S-GUIDE-UGE) y la proyección de esta última posición sobre la vía (módulo#4-RDL). Más en detalle:

  • Posición geográfica de la antena del tren en la vía (pvt0).
  • Ejemplo de posición geográfica calculada por un receptor GNSS (pvt1).
  • Nota: teniendo en cuenta la afectación de fenómenos locales y globales.
  • Ejemplo de posición geográfica dada por el Virtual Balise Reader (pvt2) para la posición pvt1.
  • Diferencia entre la posición de referencia de la baliza y de disparo de la baliza (valor de la variable dl al paso por la baliza).

Figura 7.1. Programación secuencias de ensayo en los simuladores del CEDEX [1].

Figura 7.2. Laboratorio de ensayos con la Eurocabina integrada [1].

Figura 7.3. Módulos en la ejecución de un escenario [1].

Figura 7.4. Referencias de posición GNSS.

En la figura 7.5 se pueden observar un ejemplo real de las posiciones anteriormente descritas en una sección de vía donde se ha simulado una perturbación por fallo de reloj en los satélites GPS: posición antena del tren (pvt0-negro), cálculo receptor GNSS (pvt1-azul), y cálculo Virtual Balise Reader (pvt2-rojo).

Figura 7.5. Referencias de posición GNSS del tren, del receptor, del Virtual balise Reader. Disparo de baliza [1] (imagen de la izquierda visualizada en Google Maps).

En la imagen se observa que entrando en esta zona de perturbación la posición dada por el Virtual Balise Reader (pvt2), que va retrasada respecto a la posición real del tren (pvt0), aumenta su distancia relativa con respecto a la incertidumbre (círculos rojos). Para el caso concreto de la baliza virtual 4766, el disparo de baliza se produce a una cierta distancia una vez pasada la localización teórica baliza virtual.

8. ANÁLISIS DE RESULTADOS

Para analizar los resultados se han desarrollado en el laboratorio del CEDEX, diferentes herramientas con los siguientes objetivos: visualización de las variables de interés, chequeo de los datos generados en el Virtual Balise Reader , simulación del comportamiento teórico de un equipo ETCS embarcado y, por último, comparación con los registros de la Eurocabina durante el ensayo.

Volviendo al caso concreto de la Simulación #3, con la condición de perturbación GNSS generada por un fallo de reloj en los satélites (Clock Failure) en el intervalo en distancias [3753-5624] metros del recorrido, el análisis nos revela que al entrar en dicha zona las distancias relativas de disparo de balizas (negro) respecto a la incertidumbre (fucsia) aumentan (figura 8.1). El diagrama de disparos de balizas es muy significativo (figura 8.2) y corresponde a la incertidumbre de los disparos de balizas frente a la distancia relativa a la posición de referencia de las balizas virtuales. La zona de la perturbación se corresponde a los disparos marcados en rojo, donde la incertidumbre GNSS en metros para cada baliza virtual (definida por la variable Along-Track Protection Level ) es menor que la distancia relativa de disparo. También se observa que al paso por las balizas la posición GNSS va retrasada respecto a la posición real del tren (distancias relativas positivas) excepto en una baliza que iba adelantada.

Figura 8.1. mbre frente a distancia relativa de disparo en las posiciones de las balizas.

El análisis realizado con la herramienta off-line del CEDEX con los datos obtenidos para una Eurocabina simulada de referencia anuncia la perdida de balizas en esta zona, tal como se verifica con el resultado de la JRU (en verde) del ensayo ejecutado en el laboratorio con una Eurocabina comercial.El análisis off-line permite chequear y detectar errores de enlace, por detectarse el disparo de baliza fuera de la ventana de expectación ERTMS, errores temporales en el orden de detección de las balizas, errores por no respetar las distancias mínimas y máximas dentro de un mismo grupo de balizas, y errores por superar el intervalo de confianza máximo permitido.

Figura 8.2. Diagrama de disparos de balizas en el ensayo de perturbación GNSS (Clock Failure) [1].

En la figura 8.3 se representa la velocidad programada, el perfil de velocidades seguido en el escenario y la evolución de los intervalos de confianza, con un ajuste de un error odométrico del 1 % obtenido de la experimentación. También se representa en azul el intervalo de confianza simulado, y en verde el registrado en la JRU por la Eurocabina.

Figura 8.3. Reinicio del error odométrico al paso por balizas al intervalo de confianza de disparo de baliza.

En la última fase de la evaluación de resultados, se realiza un análisis automático de los registros de laboratorio, lo que permite realizar una evaluación completa de los ensayos cargados y ejecutados en el laboratorio y completar la hoja de resultados finales en base a los siguientes registros:

  • Registros de laboratorio
  • BTM/VBT (Módulo de transmisión de telegramas de balizas).
  • RTM (Módulo de Nivel 2 de transmisión de radio).
  • TIU (Unidad de interfaz con el tren).
  • ODO (Sistema de generación de odometría).
  • Registros del equipo de una Eurocabina
  • DMI.
  • JRU (Unidad de Registrador Jurídico).

Una vez almacenada toda la información registrada en el ensayo, la automatización permite evaluar y registrar tanto en tiempo como en distancia los observables de los casos de prueba incluidos en la simulación. Un esquema del proceso se muestra en la figura 8.4.

Figura 8.4. Herramientas de automatización de análisis de escenarios [1].

De este modo, el resultado del proceso automático de evaluación de cada secuencia incluye la creación del informe final. Finalmente, cabe destacar que el proyecto GATE4RAIL ha permitido al LIF su desarrollo en los siguientes ámbitos:

  • Definición de una arquitectura de ensayos ERTMS/GNSS como solución zero-on-site-testing para acometer Plan Europeo de Despliegue ERTMS [5].
  • Evolución de los ensayos y escenarios operacionales de prueba elaborados, bancos de herramientas y los procedimientos de evaluación para el desarrollo y certificación de los futuros sistemas de seguridad.
  • Integración de registros de ensayo procedente de diferentes ámbitos y subsistemas.
  • Automatización en la evaluación de resultados de cada simulación.
  • Generación de mapas de despliegue de la vía con localización geográfica y representaciones en tiempo real del movimiento del tren medido y estimado con identificación de errores en tiempo real.
  • Colaboración con instituciones europeas y laboratorios de referencia GNSS del mayor prestigio.

Figura 8.5. Informe de resultados [1].

9. CONCLUSIONES

El proyecto europeo GATE4Rail ( GNSS Automated Virtualised Test Environment for Rail ) finalizó en febrero de 2021 con una demostración final en tiempo real dirigida desde el LIF.

En los experimentos desarrollados en el LIF se integraron los cálculos realizados por los simuladores del resto de laboratorios, permitiendo estudiar el posicionamiento por satélite GNSS en la circulación de un tren con una Eurocabina (EVC) en una línea italiana (Cagliari-San Gavino) y otra española (Amorchón-Ahondiguilla).

El diseño de la arquitectura e interfaces entre los socios europeos del consorcio permite ensayar tanto en condiciones nominales de GNSS, como en presencia de efectos locales y globales que afecten a la señal GNSS, así como estudiar el impacto sobre diferentes configuraciones de balizas virtuales en las circulaciones ERTMS.

El hecho de que en el laboratorio se registre con precisión la posición real del tren permite analizar las desviaciones en comparación con la estimada a bordo, y lo convierte en una herramienta fundamental tanto para la experimentación como para la verificación de líneas ERTMS con tecnologías GNSS, tal como se ha demostrado en este proyecto. A continuación de muestra un breve resumen de los logros del proyecto GATE4RAIL:

  • La integración de módulos diferentes tanto de ERTMS como de GNSS repartidos en Centros de Investigación Europeos ha posibilitado la creación de una plataforma zero-onsite-testing .
  • Los resultados obtenidos soportan favorablemente el concepto de baliza virtual como medio de reducir los costes de ERTMS.
  • La arquitectura de ensayo del GATE4Rail se considera una plataforma útil para:
  • Evaluar el nuevo concepto de baliza virtual en los proyectos ERTMS.
  • Validar las líneas ERTMS con ingenierías basadas en balizas virtuales y como herramienta de diseño para la creación de nuevas líneas.
  • Certificar los equipos Virtual Balise Reader bajo condiciones GNSS nominales, reales y degradadas.
  • Evaluar el uso de GNSS para la localización del tren.
  • Integración de GNSS y en ERTMS:
  • La localización segura del tren es de vital importancia en los sistemas de control y protección del tren.
  • Se requiere introducir nuevas especificaciones europeas que sean obligatorias para la integración de la tecnología GNSS en el ferrocarril, manteniendo la interoperabilidad del ERTMS.
  • Por todo ello, se considera que la arquitectura diseñada en el proyecto GATE4Rail es un punto de arranque prometedor para conseguir estos objetivos.

El uso del GNSS se encuentra en pleno proceso integración en aplicaciones ferroviarias comerciales. El CEDEX a través de varios proyectos de innovación europeos (VITE, ERSAT-GGC y GATE4RAIL) ha trabajado en el uso del GNSS en el ERTMS desde el 2015 y es esta madurez la que ha permitido embarcar al CEDEX, junto con INECO y ADIF, en un consorcio internacional de 12 empresas en el proyecto europeo RAILGAP ( RAILway Ground truth and digital mAP ) [6] dentro del programa Horizon 2020 con una duración hasta enero de 2023.

El proyecto RAILGAP supone un paso más en la integración del GNSS en el ERTMS y en la digitalización del ferrocarril mediante el estudio de nuevos sensores (receptores GNSS, sensores inerciales, cámaras estereoscópicas y LIDAR) embarcados en trenes comerciales o de mantenimiento con el objetivo de registrar y evaluar datos de la vía dando lugar a la creación de mapas digitales precisos y su mantenimiento.

La combinación de fusionar los datos obtenidos por diferentes sensores y memorizar estos mapas a bordo nos permitirá conocer en todo momento nuestra posición y dirección, y así llegar de una forma segura a nuestro destino además de la creación de gemelos digitales en laboratorio para su análisis y evaluación. De este modo, la experimentación en laboratorio y en vía nos permitirá establecer las estrategias de navegación que mejor se adapten a nuestro sistema de control y protección del tren y a las circunstancias que lo rodean.

El desarrollo de la movilidad y del transporte en nuestra sociedad nos ha llevado a diseñar y crear sofisticados sensores, algoritmos, herramientas, equipos, sistemas [4] tales como los sistemas de posicionamiento por satélite [3] (o antiguamente el sextante, la brújula, el astrolabio o el mecanismo de Anticitera) sin dejar de lado el estudio de las diferentes técnicas de navegación desarrolladas a lo largo de años de evolución por los animales en su estrategia de una mayor supervivencia en la Tierra, utilizando diferentes métodos a través de la vista, el olfato, el tacto, el campo magnético, mapas del territorio y del cielo estrellado, mapas sensoriales que usan en sus migraciones o vuelta a casa [8].

10. AGRADECIMIENTOS

A Shift2Rail y a todos los socios que han participado en el proyecto. Es de destacar la buena sintonía y colaboración entre todos los participantes durante los dos años de duración del proyecto, lo que ha permitido crear un ambiente creativo, de trabajo y de colaboración, y a obtener unos resultados más que satisfactorios.

El proyecto GATE4Rail ha sido financiado por Shift2Rail (Grant Agreement 826324).

11. REFERENCIAS

[1] Web proyecto GATE4Rail: http://gate4rail.eu/

[2] Web proyecto ERSAT-GGC: http://www.ersat-ggc.eu/

[3] Herranz, S., Campo, R., Molina, D., y Bueno, J. (2020). La tecnología GNSS en el sistema de señalización ERTMS. GNSS Technology in the ERTMS Signalling System. Ingeniería Civil , nº 197, pp. 74-89.

[4] Iglesias, I.J., Campo, R., y Estaire, J. (2020). La digitalización del ferrocarril. The Railway Digitalization. Ingeniería Civil , nº 197, pp. 62-73.

[5] Iglesias, J.I., Bueno, J., Molina, D., Herranz, S., Cáceres, R., Fernández, M., y López, M. (2019). El papel del laboratorio de Interoperabilidad Ferroviaria del CEDEX en el proceso de puesta en servicio de líneas y trenes ERTMS. The Role of CEDEX Rail Interoperability Lab in the Process of Placing in Service ERTMS Lines and Trains. Ingeniería Civil , nº 194, pp. 20-24.

[6] Web proyecto RAILGAP: http://www.railgap.eu/

[7] Web Proyecto UseGalileo: https://www.usegalileo.eu/

[8] Hill, R.W., Wyse, G.A., y Anderson, M. (2016). Integration Systems at Work: Animal Navigation. En Richard W. Hill, Gordon A. Wyse y Margaret Anderson, Animal Physiology , 4th edition. Sunderland, MA/USA: Sinauer Associates Inc.

NOTAS

1 El caso de prueba genérico recoge de forma detallada la funcionalidad ERTMS o fenómeno GNSS sin especificar su localización exacta en la vía.