¿Por qué chocaron el AVE y el Iryo en Urda? La realidad técnica detrás del accidente según la IA

¿Por qué chocaron el AVE y el Iryo en Urda? La realidad técnica detrás del accidente según la IA
RESUMEN DEL MENSAJE INICIAL · elaborado con IA

El accidente ferroviario de Urda no lo provocó un fallo informático, sino el estado del cableado físico de la vía. El sistema LZB se apagó por seguridad al detectar cortes y humedad, el ASFA quedó ciego por la misma infraestructura degradada y el AVE acabó rebasando señales en rojo con la protección anulada.

Leer el resumen completo →

El accidente ferroviario de Urda no lo provocó un fallo informático, sino el estado del cableado físico de la vía. El sistema LZB se apagó por seguridad al detectar cortes y humedad, el ASFA quedó ciego por la misma infraestructura degradada y el AVE acabó rebasando señales en rojo con la protección anulada.

El accidente ferroviario de Urda no empezó en un servidor. Empezó en un cable. El sistema LZB, el que gobierna la seguridad de la alta velocidad, no se cayó por un virus ni por un error de software: se apagó porque detectó cortes, micro-roturas y humedad en el cableado físico de la vía. Y lo hizo aplicando el principio de «fallo seguro», que consiste en inmovilizar el tren antes que dar una información errónea. El Iryo se paró. La tecnología cumplió su diseño.

170 caídas en un año y un cable sin repuestos

El ministro de Transportes admitió que el sistema se había caído 170 veces en un año. Cada uno de esos cortes obligaba a los operadores humanos a activar protocolos manuales para que la línea no se congelara. El cable afectado está obsoleto y sin repuestos, según el relato técnico del caso. Ahí está el problema de fondo: una infraestructura que se degrada más rápido de lo que se mantiene.

Cuando el LZB se apaga, la seguridad pasa al respaldo, el ASFA. Pero las balizas del suelo tampoco son mágicas: dependen de cables conectados a las señales. Con la infraestructura degradada, esas balizas empezaron a dar lecturas erróneas y falsas alarmas. El segundo sistema también quedó ciego por la misma causa física.

La orden de rebasar señales en rojo

Ante el caos en la vía, el Centro de Control pasó a la conducción manual. Para evitar el colapso de la línea, se autorizó al AVE a rebasar señales en rojo. Al ejecutar esa orden, el maquinista debe anular temporalmente la acción del ASFA. Fue en ese vacío de protección total donde el AVE avanzó por la misma vía donde el Iryo seguía parado.

Ningún software de seguridad de última generación sobrevive a una infraestructura física descuidada. La tecnología se apagó para protegerse; el peligro real surgió cuando la falta de inversión obligó al factor humano a gestionar la alta velocidad a ciegas.

Datos clave
  • El LZB se cayó 170 veces en un año por cortes y humedad en el cableado, según admitió el ministro de Transportes.
  • El cable afectado está obsoleto y sin repuestos, lo que impide sustituirlo con rapidez.
  • El ASFA, sistema de respaldo, depende de balizas conectadas por cable a las señales y dio lecturas erróneas.
  • El Centro de Control autorizó al AVE rebasar señales en rojo, lo que obliga a anular temporalmente el ASFA.
  • El principio de «fallo seguro» inmovilizó al Iryo al detectar el fallo físico, no un virus informático.
Resumen generado con inteligencia artificial a partir del primer mensaje del tema.

Corvo de Xallas

Madmaxista
Desde
11 Mar 2009
Mensajes
4.865
Fruta
12.313
Lugar
Xallas
Mucho se ha hablado de "fallos informáticos", pero la verdadera causa del accidente ferroviario de Urda apunta a algo mucho más físico y terrenal: el estado de los cables y la falta de mantenimiento en las vías.
Aquí te resumo las claves técnicas de cómo fallaron en cadena los sistemas de seguridad:
  • El sistema LZB funcionó "demasiado bien": Los ordenadores centrales no fallaron por un bicho. Al detectar cortes, micro-roturas o humedad en el cableado físico de la vía, el sistema aplicó el principio de "Fallo Seguro": prefirió apagarse por seguridad e inmovilizar al tren Iryo antes de arriesgarse a dar una información errónea.
  • La trampa de los 170 cortes previos: El ministro de Transportes admitió que el sistema se había caído 170 veces en el año. Cada corte del cable (obsoleto y sin repuestos) obligaba a los operadores humanos a activar protocolos manuales para no congelar por completo el tráfico de la línea.
  • El ASFA también quedó "ciego" por lo mismo: Al caerse el LZB, la seguridad pasó al sistema de respaldo (ASFA). Pero las balizas del suelo tampoco son mágicas; dependen de cables conectados a las señales. Con la infraestructura degradada, las balizas empezaron a dar lecturas erróneas y falsas alarmas.
  • La anulación manual del sistema: Ante el caos físico en la vía, el Centro de Control tuvo que pasar a la conducción manual. Para evitar el colapso de la línea, se autorizó al AVE a "rebasar señales en rojo". Al liquidar esta orden humana, el maquinista debe anular temporalmente la acción del ASFA. Fue en ese vacío de protección total donde el AVE avanzó por la misma vía donde el Iryo seguía parado.
En resumen: Ningún software de seguridad de última generación sobrevive a una infraestructura física descuidada. La tecnología cumplió su diseño y se apagó para protegerse; el peligro real surgió cuando la falta de inversión obligó al factor humano a gestionar la alta velocidad "a ciegas".
 
Mucho se ha hablado de "fallos informáticos", pero la verdadera causa del accidente ferroviario de Urda apunta a algo mucho más físico y terrenal: el estado de los cables y la falta de mantenimiento en las vías.
Aquí te resumo las claves técnicas de cómo fallaron en cadena los sistemas de seguridad:
  • El sistema LZB funcionó "demasiado bien": Los ordenadores centrales no fallaron por un bicho. Al detectar cortes, micro-roturas o humedad en el cableado físico de la vía, el sistema aplicó el principio de "Fallo Seguro": prefirió apagarse por seguridad e inmovilizar al tren Iryo antes de arriesgarse a dar una información errónea.
  • La trampa de los 170 cortes previos: El ministro de Transportes admitió que el sistema se había caído 170 veces en el año. Cada corte del cable (obsoleto y sin repuestos) obligaba a los operadores humanos a activar protocolos manuales para no congelar por completo el tráfico de la línea.
  • El ASFA también quedó "ciego" por lo mismo: Al caerse el LZB, la seguridad pasó al sistema de respaldo (ASFA). Pero las balizas del suelo tampoco son mágicas; dependen de cables conectados a las señales. Con la infraestructura degradada, las balizas empezaron a dar lecturas erróneas y falsas alarmas.
  • La anulación manual del sistema: Ante el caos físico en la vía, el Centro de Control tuvo que pasar a la conducción manual. Para evitar el colapso de la línea, se autorizó al AVE a "rebasar señales en rojo". Al liquidar esta orden humana, el maquinista debe anular temporalmente la acción del ASFA. Fue en ese vacío de protección total donde el AVE avanzó por la misma vía donde el Iryo seguía parado.
En resumen: Ningún software de seguridad de última generación sobrevive a una infraestructura física descuidada. La tecnología cumplió su diseño y se apagó para protegerse; el peligro real surgió cuando la falta de inversión obligó al factor humano a gestionar la alta velocidad "a ciegas".
Debería haber ido a 40 km/h y aplicar la norma de seguridad: circulación a la vista.

La responsabilidad última es del maquinista.

La última responsabilidad. Las anteriores son de Atocha y del deficiente mantenimiento.
 
Debería haber ido a 40 km/h y aplicar la norma de seguridad: circulación a la vista.

La responsabilidad última es del maquinista.

La última responsabilidad. Las anteriores son de Atocha y del deficiente mantenimiento.
La culpa fue de los maquinistas; después de 170 fallos tendrían que haber dejado de conducir los trenes.
 
Entonces ¿todos los cms del PSOE rojo que afirmaban que la causa era un bicho de los hebreo resulta que mintieron?

Me pinchan y no sangro de la impresion.

Es que no se donde vamos a parar cuando foreros de tanta confianza resulta que mienten
 
Entonces ¿todos los cms del PSOE rojo que afirmaban que la causa era un bicho de los hebreo resulta que mintieron?

Me pinchan y no sangro de la impresion.

Es que no se donde vamos a parar cuando foreros de tanta confianza resulta que mienten
Sí, estás en lo cierto. Los ordenadores que gestionan estos sistemas críticos de seguridad ferroviaria están completamente aislados de internet (lo que en ciberseguridad se conoce como Air Gap o brecha de aire).
Para introducir un bicho o modificar su software no se puede hacer mediante un ataque remoto por la red; se requiere acceso físico directo al hardware.
La realidad técnica de cómo se actualizan y protegen estos sistemas incluye los siguientes aspectos:

1. ¿Cómo se introduce información en un sistema aislado?

Dado que los sistemas como el LZB o el ASFA se diseñaron hace décadas (o siguen protocolos industriales extremadamente estrictos en sus versiones modernas), no tienen navegadores web ni conexiones de red externas:
• Disquetes y cartuchos físicos: En las versiones más antiguas del LZB (como el de la línea Madrid-Sevilla inaugurada en 1992), las actualizaciones de software o la carga de datos de las rutas se hacían literalmente mediante disquetes de 3.5 pulgadas o cartuchos de memoria específicos de la época.
• Memorias dedicadas o PC de mantenimiento: En sistemas un poco más actualizados o en el ASFA Digital, un técnico autorizado debe acudir físicamente con un ordenador portátil de mantenimiento homologado o una memoria USB cifrada y conectarse mediante un cable físico (como un puerto serie o Ethernet industrial) directamente al armario del rack del ordenador.

2. El peligro del "enemigo interno" o el descuido

El aislamiento total de internet los hace inmunes a los hackers convencionales que operan desde el otro lado del mundo, pero no los hace 100% infalibles. El riesgo real en estos entornos proviene de:
• Infección indirecta (el "Efecto Stuxnet"): El caso más famoso del mundo de un bicho que saltó un aislamiento de internet ocurrió en la central nuclear de Natanz (Irán). El bicho Stuxnet entró porque alguien introdujo una memoria USB infectada (proveniente de un ordenador de oficina que sí tenía internet) en los ordenadores industriales. En el ferrocarril, si una laptop de mantenimiento se contamina en la oficina y luego se conecta al tren, el bicho puede saltar.
• Sabotaje físico: Al requerir presencia física, cualquier modificación maliciosa exigiría que alguien con llaves, credenciales y acceso a las salas técnicas de Adif o a las cabinas de los trenes introdujera el software dañino.

3. Por qué se refuerza la teoría del fallo físico en Urda

Precisamente porque estos ordenadores están blindados contra ataques externos de internet, la teoría de un "ciberataque masivo" que tumbara el sistema en Urda fue descartada rápidamente por los investigadores.
Un bicho informático no provoca de forma selectiva micro-cortos intermitentes (los 170 fallos previos). Los bicho borran datos, congelan pantallas o alteran parámetros. El comportamiento de la línea (caídas continuas que se recuperaban solas o que obligaban a rearmar los equipos) encaja a la perfección con cables de cobre en mal estado, humedades en las canalizaciones de la vía o balizas sulfatadas. La física de la infraestructura falló mucho antes que la informática del sistema.
Si te interesa el tema de la seguridad informática ferroviaria, dime si te gustaría saber cómo el nuevo sistema ERTMS (que sí utiliza señales de radio digitales) se protege para evitar que intercepten sus comunicaciones.
 

Estadísticas del foro

Temas
2.062.812
Mensajes
58.545.310
Miembros
191.130
Último miembro
Grupo-Homes

El blog de burbuja.info

-
Volver