Hola a todos,
El quid de la cuestión es que TrainController está inspirado por el sistema Hp de los ferrocarriles alemanes, en los que el aspecto amarillo=velocidad restringida nunca, repito nunca, indica una circunstancia de tráfico (es decir, otros trenes) sino una propia de la vía, tal y como la toma de desvíos en posición curva.
Por las intervenciones de Alfred y de Leoballes veo que esa práctica es la también usada por Renfe y hasta donde he podido comprobar, por todos los ferrocarriles del mundo. (¡Ojo! Otra cosa totalmente diferente es el empleo de señales avanzadas, pero más de esto luego)
Por tanto el TrainController sigue y seguirá exactamente igual en cuanto al uso de la “señal interna calculada” que es la que determina la velocidad a la que se SALE del bloque y se recorre el bloque siguiente. Esa señal interna calculada solamente será amarilla si el bloque siguiente debe de recorrerse a velocidad restringida, y esa es una propiedad que depende del bloque o ruta, pero NO del tráfico y no puede ser forzada a ser de otra manera.
Así, en el recorrido famoso A-B-C, con tren ocupando C y nuestro tren llegando a A. Las velocidades ‘normales’ definidas para cada bloque son iguales.
Como A está libre, la señal de salida (interna calculada) del bloque anterior (sería bloque 0, por entendernos) será verde. A se recorre a su velocidad normal.
Como el tren también puede entrar en B, la señal interna calculada de A seguirá siendo verde, y el tren saldrá de A y entrará en B sin variar su velocidad.
Pero como el tren no debe salir de B (su señal interna calculada es rojo) en cuanto se alcance el indicador de frenada de B, el tren comenzará a decelerar hasta llegar a la salida de B donde el indicador de paro lo detendrá. Al nivel del indicador de frenada es donde deberíamos colocar la señal avanzada de B si ésta existe.
Vale, pero esto son las señales internas calculadas del TrainController, en las que como veis NO interviene ningún amarillo por cuestiones de tráfico, y que pueden tener que ver o no con las señales físicas que nosotros coloquemos al lado de la vía y que además según las administraciones ferroviarias usan diferentes combinaciones de colores.
Aquí es donde se aplica todo el ejemplo realizado por Pere. Usando triggers y condiciones podemos hacer que estas señales físicas puedan permitir indicar un estado de tráfico que vaya más allá de mirar “dos bloques adelante”. Pero ojo, recordemos que en este caso se trata de señales avanzadas, no principales.
Este mirar hacia delante tiene sentido en el tren real en líneas de alta velocidad o de alta densidad de tráfico, y por lo que me he informado, en Alemania corresponden más a avisos que el conductor recibe en el ordenador de su cabina que a señales existentes físicamente.
En las maquetas es otro cantar ya que por razones de espacio/tiempo a todos nos gusta meter los trenes bien seguidos y apretados unos detrás de otros y no sé por qué narices es siempre el tren rápido el que va siguiendo –a tirones- al tren lento .
Pues bien, ahora la duda es como hacer que esas señales avanzadas y preavanzadas tengan influencia en la velocidad del tren. La posibilidad actual es la chapuza que tan amablemente Pere califica como solución. Usar ‘Engine operations, speed’. El problema es que es un comando externo al Dispatcher y éste tratará tan pronto como sea posible de retomar el control de la situación.
Bueno, pues eso es lo que se le ha planteado a Freiwald, y lo único que puedo anticipar es que ha sido muy receptivo e incluso anticipado alguna solución “limpia” creo que totalmente satisfactoria.
Salud para los que sigan despiertos.
JM
