Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización

Equation Chapter 1 Section 1 Trabajo Fin de Máster Ingeniería Industrial Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización Autor: Rafael Angulo Limberg Tutor: Antonio Jesús Sánchez Herguedas Dpto. Organización Industrial y Gestión de Empresa I Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2025 Trabajo Fin de Máster Ingeniería Industrial Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización Autor: Rafael Angulo Limberg Tutor: Antonio Jesús Sánchez Herguedas Profesor Titular de Universidad Dpto. de Organización Industrial y Gestión de Empresas I Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2025 4. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización 5. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización Trabajo Fin de Máster: Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización Autor: Rafael Angulo Limberg Tutor: Antonio Jesús Sánchez Herguedas El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2025 El Secretario del Tribunal 6. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización A todos aquellos que se dedicarán a la seguridad ferroviaria 7. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización Agradecimientos Todos los estudiantes pasan por momentos de dudas a la hora de tomar decisiones acerca de su futuro profesional. Algunos de ellos las sufren a la hora de elegir carrera, otros durante la misma y, en mi caso, surgieron a la hora de apostar por mi primer trabajo. Diferentes oportunidades aparecieron ante mí a finales del segundo curso del doble máster y en aquel momento, los consejos del profesor D. Alejandro Escudero Santana me ayudaron para tomar mi decisión. Este trabajo es buena muestra que aquella decisión fue la correcta. Quiero aprovechar este espacio para darle las gracias a él y a todos aquellos profesores que nos guían y nos acompañan a lo largo de nuestras vidas académicas y en la transición al mundo profesional. Gracias, profesor. Con la entrega de este trabajo concluye mi vida académica y es momento de agradecer a todas aquellas personas que me han acompañado. Gracias de mis padres, a mi pareja, a mi familia y a mis amigos. Habéis sido fundamentales para llegar a este punto. 8. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización 9. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización Resumen La ingeniería ferroviaria, y en concreto la seguridad ferroviaria, no posee una carrera universitaria específica por lo que es difícil que algún estudiante realice una carrera universitaria con el objetivo de trabajar en este sector. Este trabajo pretende ser una introducción a los conocimientos básicos que debe conocer y a las tareas que debe realizar un ingeniero de seguridad ferroviaria. Es un trabajo que requiere del conocimiento de la normativa CENELEC y del manejo de mucha documentación, además de la proactividad de los ingenieros por descubrir y conocer el funcionamiento del sistema de señalización en detalle. En este trabajo se puede encontrar una aproximación a los elementos que componen el subistema de señalización y una breve descripción de cada una de ellas, el resumen de la normativa CENELEC que aplica en los proyectos; la metodología de las tareas que realiza un ingeniero de seguridad y la descripción de los principales documentos de seguridad. 16. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización Glosario DRP Declaración de Riesgos Previa DT Data Testing HW Hardware ISA Evaluación Independiente de Seguridad (en inglés, Independent Safety Assessment) IxL Enclavamiento (en inglés, Interlocking) PeS Puesta en Servicio PHA Análisis Preliminar de Riesgos (en inglés, Preliminary Hazard Analysis) PK Punto Kilométrico RAMS Fiabilidad, Disponibilidad, Mantenimineto & Segruidad (en inglés Reliability, Availability, Maintenance & Safety) SC Informe Caso de Seguridad (en inglés, Safety Case report) SIL Nivel de Integridad de la seguridad (en inglés, Safety Integrity Level) SRAC Condición de Aplicación Relacionada con la Seguridad (en inglés, Safety Related Application Condition) SW Software T&C Pruebas y Puesta en Servicio (en inglés, Test and Commissioning) V&V Verificación y Validación 17. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización 18. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización 1 ALCANCE Y MOTIVACIÓN El presente Trabajo de Fin de Máster se encuadra en el marco del Máster en Ingeniería Industrial, en adelante MII, como trabajo de conclusión de estudios. El objetivo del trabajo reside en la elaboración de una guía para la introducción de la gestión de la seguridad en los proyectos de señalización ferroviaria. Tras la propia experiencia del autor en el sector, se ha detectado que la existencia de literatura acerca de la normativa vigente en este tipo de proyectos es bastante escasa y, mediante el presente trabajo, se pretende recopilar unas nociones básicas que sirvan de ayuda a aquellas personas que se quieran adentrar en el sector del RAMS ferroviario, lo que da lugar a la motivación del trabajo. Los proyectos de ingeniería requieren un estudio completo de eficiencia y rendimiento para garantizar la máxima productividad del sistema. Este estudio se enmarca en el el análisis RAM (en inglés Reliability, Availability y Maintenance), donde se analizan los aspectos claves de fiabilidad, disponibilidad y mantenimiento de un sistema y que conforman el núcleo de un producto de ingeniería. Sin embargo, este estudio no es suficiente cuando en el sistema se ven involucrados los seres humanos. En aquellas aplicaciones donde para operar el sistema se incurren en riesgos potencialmente peligrosos para los operadores, medios y medioambiente, es necesario realizar un estudio de seguridad dando lugar al RAMS (incluyendo en inglés Safety). Mediante este estudio de seguridad, se identificarán los riesgos, se analizarán y mitigarán los mismos y para todo ello se cumplirá con la normativa que lo regula. Dado lo anterior, el alcance del presente trabajo es focalizar el estudio de los proyectos ferroviarios en la normativa de aplicación de la seguridad ferroviaria. Para ello, se analizarán las normas CENELEC 50126, 50128 y 50129, refs. [1], [2], [3] y [4], que se aplican en los proyectos nacionales e internacionales. De este modo, todos los procesos relacionados con la verificación y validación de los requisitos y el cierre de amenazas quedarán expuestos en los capítulos posteriores. Para proyectos que se realicen en Europa y que se encuentren en la Red Ferroviaria de Interés General 1 , también aplica el reglamento 402 de la Unión Europea. Este reglamento queda fuera del alcance del trabajo para ampliar su aplicación a los proyectos internacionales fuera de la UE. En cualquier caso, el cumplimiento de la normativa CENELEC asegura el cumplimiento del reglamento 402. En desarrollo de este trabajo se comenzará por esta introducción donde se definen la motivación y el alcance. En el capítulo 2 se describen los sistemas ferroviarios de manera global, presentando todos los subsistemas involucrados en un proyecto ferroviario, los tipos de proyectos que se dan relacionados con la señalización y los productos genéricos que conformar el subsistema de señalización ferroviaria. Tras esta introducción, en el capítulo 2.3 se presentarán los aspectos claves de las tres normas CENELEC sobre las que se sustentan los estudios de seguridad. Se identificarán los procesos que son necesarios realizar para asegurar que los proyectos cumplen con la normativa de seguridad y, éstos serán después descritos detalladamente. La metodología de las actividades del ingeniero de seguridad es descrita en el capítulo 4. Se desarollarán todas aquellas actividades donde el ingeniero de seguridad debe participar y se relacionarán con las fases del ciclo de vida. Por último, en el capítulo 5 se procederá a describir detenidamente cada uno de los documentos de seguridad, los cuales son el core del estudio de seguridad. Mediante estos documentos, el ingeniero de seguridad puede evidenciar que el proyecto cumple con los estándares impuestos por la normativa vigente. 1 La Red Ferroviaria de Interés General (RFIG) integra todas aquellas infraestructuras ferroviarias que resultan esenciales para garantizar un sistema común de transporte ferroviario en todo el territorio del Estado o cuya administración conjunta resulte necesaria para el correcto funcionamiento de tal sistema común de transporte. Quedan fuera de la RFIG los transportes metropolitanos (metro) o aquellas líneas de carácter privado, como los cercanías gestionados por las comunidades autónomas FGC (Ferrocarrils de la Generalitat de Catalunya) o Euskotren (Ferrocarriles del País Vasco). 19. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización En el anexo se incluye un listado de documentación genérico de un proyecto. Para cualquier proyecto este listado puede más extenso si incluye más productos o menos en el caso que incluyan modificación sobre menos elementos. Una vez concluida la presentación de todos los capítulos anteriores, el ingeniero de seguridad debe ser capaz de comprender las bases de los estudios de seguridad de los proyectos de señalización ferroviaria y, mediante la acumulación de experiencia profesional con los productos fabricados por los diferentes tecnólogos, estará en disposición de adentrarse en el sector de la seguridad ferroviaria. Todo lo que se presenta en este trabajo ha sido extraído de la experiencia profesional del autor y de la normativa CENELEC. 20. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización 2 INTRODUCCIÓN A LOS SISTEMAS FERROVIARIOS Los sistemas ferroviarios abarcan múltiples campos que son abordados a la hora de ejecutar un proyecto que implique modificaciones en las vías ferroviarias. En este capítulo se va a realizar una introducción a los sistemas ferroviarios presentando en primer lugar todos los subsistemas, en el capítulo 2.1, y posteriormente, focalizando la atención en el subsistema de señalización, objeto del trabajo, con la descripción de los elementos que lo conforman en el capítulo 2.2 y los diferentes tipos de proyectos que se dan en la actualidad, en el capítulo 2.3. 2.1 Subsistemas involucrados en un proyecto ferroviario Según el Real Decreto 929/2020, los sistemas ferroviarios se dividen en los subsistemas de de naturaleza estructural y aquellos de naturaleza funcional. Los subsistemas de naturaleza estructural engloban los siguientes subsistemas: ❖ Infraestructura. Este subsistema comprende todos aquellos elementos físicos de las vías ferroviarias desde la obra civil (estructuras, puentes, túneles), pasando por los pasos a nivel hasta todos los elementos relacionados con las estaciones (andendes, zonas de espera, accesos y salidas, etc.). Ilustración 1. Estación de la línea 1 del Metro de Sevilla. ❖ Energía. Este subsistema incluye los sistemas encargados de dotar de energía eléctrica a la operación de los ferrocarriles, como el sistema de electrificación donde se incluyen las líneas aéreas o el equipo en tierra para la medición y tarificación del consumo de electricidad. 21. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización Ilustración 2. Subsistema de energía en el Metro de Sevilla. ❖ CMS – Control, mando y señalización (equipo de vía). Este subsistema se compone de todos aquellos elementos que permiten garantizar la seguridad en la operación de sistema ferroviario. Este subsistema es objeto del trabajo y se estudiará en profundidad en los próximos capítulos. ❖ CMS – Control, mando y señalización (equipo de embarcado). Este subsistema, de igual forma que con el equivo de vía, se compone de todos los elementos que permiten garantizar la operación segura de la red ferroviaria desde el punto de visto de los equipos a bordo del tren. ❖ Material rodante. Este subsistema contiene todos los elementos físicos necesarios de los que se compone un tren, desde los sistemas eléctricos, equipos de frenado y acoplamiento, hasta las interfaces máquina-humano y los servicios a bordo del tren pasara el personal y los viajeros. Ilustración 3. Subsistema CMS en vía y en embarcado. 22. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización Estos subsistemas aparecen representados en la Ilustración 4: Ilustración 4. Esquema de subsistemnas de naturaleza estructural. Por otro lado, los subsistemas de naturaleza funcional son los siguientes: ❖ Explotación y gestión del tráfico. Este subsistema incluye aquellos procedimientos y equipamientos asociados que permiten explotar el sistema de forma coherente tanto en condiciones normal como en condiciones degradadas. Ilustración 5. Centro de control del tráfico ferroviario. ❖ Mantenimiento. Este subsistema contiene los procedimientos, equipos necesarios y las instalaciones logísticas necesarias para llevar a cabo las acciones de mantenimiento correctivo y preventivo. ❖ Aplicaciones telemáticas para servicios de viajeros y de transporte de mercancías. Este subsistema se compone de dos partes: la primera de ellas consiste en las aplicaciones para los viajeros, como la gestión de reservas o la información sobre los viajes; y la segunda consiste en las aplicaciones para los servicios de transporte de mercancías, que incluyen entre otras características la gestión de documentos electrónicos de acompañamientos necesarios para el transporte de mercancías. 23. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización Todos estos subsistemas comparten unos requisitos generales en materia de seguridad, fiabilidad y disponibilidad, salud, protección del medio ambiente, compatibilidad técnica y accesibilidad. De igual forma, todos los subsistemas poseen sus propios requisitos específicos en las mismas materias de los requisitos generales. En el marco de un proyecto ferroviario se establecen las características técnicas preliminares de los subsistemas. Dentro de las características técnicas preliminares se encuentran las características generales como el tipo de tráfico, el ancho de vía o las velocidades de diseño de la vía, las interfaces, los elementos singulares o las novedades técnicas. Una vez se han definido todos los subsistemas que componen los sistemas ferroviarios, nos adentraremos en el subsistema objeto de este trabajo, el subsistema Control, Mando y Señalización. En los próximos capítulos se describirán los principales productos de los que se compone este subsistema. 2.2 Productos genéricos en la señalización ferroviaria El subsistema Control, Mando y Señalización del equipo de vía se nutre de diferentes productos para garantizar la seguridad en la operación del sistema. En este apartado, se va a realizar un recorrido por todos aquellos productos que componen el subsistema CMS. 2.2.1 Enclavamiento El enclavamiento es el producto más importante del subsistema CMS ya que es el sistema que controla los elementos de señalización de los equipos en la vía. Según el diccionario de Adif, ref. [5], el enclavamiento se puede definir de la siguiente manera: “relación de dependencia entre la posición de los dispositivos de accionamiento de aparatos de vía, barreras, señales, etc., que deben ser accionados en un determinado orden con objeto de garantizar la seguridad de la circulación mediante la posición adecuada de todos los aparatos de vía y de las señales de una estación o puesto, impidiendo movimientos peligrosos para el recorrido de una circulación autorizada”. Los enclavamientos pueden ser de diferentes tipos: ❖ Enclavamientos mecánicos, accionados mediante palancas, levas y poleas. ❖ Enclavamientos electromecánicos, basados en relés de seguridad. ❖ Enclavamientos eléctrónicos, fundamentados en microprocesadores. Los primeros enclavamientos existen fueron los de tipo mecánicos, que son datados del siglo XIX. Éstos surgieron de la necesidad de la reducción de los accidentes y del coste de personal de operación de las estaciones tras el aumento del tráfico ferroviario. Actualmente, los nuevos enclavamientos que son instalados son de tipo electrónico y suministrados por los múltiples tecnólogos como Siemens con la tecnología Westrace, Thales y su producto Intersig L90E, L90P, Altsom con la familia de enclavamientos Onvia Lock o Enyse con el enclavamiento EiS23. 24. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización 2.2.2 Señales El siguiente producto utilizado en el subsistema CMS son las señales en la vía, las cuales se utilizan para indicar al maquinista las próximas situaciones que se va a encontrar en la vía. En los sistemas ferroviarios, dado la necesidad de una mínima distancia para reducir la velocidad del tren, es necesario que se anuncien los diferentes estados de la vía como desvíos, disminuciones de velocidad o paradas, con suficiente antelación. Las señales pueden ser de diferentes tipos según su modo de funcionamiento: ❖ Señales mecánicas, las cuales no disponen de focos de luz e indican el aspecto mediante un elemento móvil. ❖ Señales mediante focos de colores, las más comunes, indican los aspectos mediante un color. ❖ Señales mediante posición de luces, que combinan las características de los dos tipos anteriores. ❖ Señales de placa fija, que son aquellas que no cambian su aspecto. ❖ Señales alfanuméricas. Según la normativa de Adif de señalización, NAS811, existen dos tipos de señales de referencia: las señales fijas fundamentales y las señales fijas indicadoras. Éstas se describen a continuación: ❖ Señales fijas fundamentales y pantallas de ERTMS N2 ❖ Señales fijas indicadoras de entrada, entrada interior, salida y salida interior para permitir la entrada o salida de la estación. Éstas pueden estar localizadas tanto en vía general como en vía de apartado. ❖ Señales fijas indicadoras de maniobra y retroceso, tanto delante de la punta de la aguja como delante del talón de la aguja. Estas señales se utilizan para movimientos de maniobra. ❖ Señales de avanzada, utilizadas para anunciar la entrada a una estación y localizada previa a una señal de entrada. ❖ Señales de indicación de velocidad. ❖ Señales de indicación de posición de aguja. ❖ Señales indicadoras de dirección. Estas señales suelen ser suministradas por proveedores externos al tecnólogo, como Electrans o Enea. Ilustración 6. Tipos de señales 25. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización 2.2.3 Desvíos Un desvío es un aparato de vía que permite que los trenes cambien de una vía a otra de forma mecánica mediante agujas, que introduciendo un ángulo muy pequeño en la dirección tangencial de la vía permite la separación gradual hasta completar el cambio de vía. Existen tres tipos de aparatos de vía: ❖ Desvíos, donde se produce el cambio entre una vía, denominada vía directa, y la otra vía denominada desviada. ❖ Escape o diagonal, se compone de dos desvíos colocados en vías en paralelo y que las conectan en ambos sentidos. En este tipo de aparto de vía sus vías desviadas se encuentran conectadas y las agujas suelen ser conjugadas, es decir, el movimiento de una condiciona a la otra. ❖ Bretelle, que se constituye de dos diagonales superpuestas conectando dos vías en paralelo y donde se produce un cruzamiento en la parte central del aparato de vía. Ilustración 7. Tipos de aparatos de vía. Los aparatos de vía se componen de tres partes esenciales para producir un desvió: el cambio, la zona intermedia y el cruzamiento. El cambio es la zona principal donde comienza el desvío y donde se encuentran las agujas. En concreto, el cambio consta de dos conjuntos de aguja-contraaguja. Las agujas son la parte móvil del cambio que permiten que el tren siga en su vía o tome el desvío y para ello se componen de la punta, la parte fija, y el talón la parte móvil. La movilidad del talón de la aguja es proporcionada por un accionamiento. Estos accionamientos originalmente fueron mecánicos y consistían en palancas manuales accionadas por los operarios. Este tipo de accionamiento mecánico se denomina marmita. Actualmente, los nuevos accionamientos suelen ser eléctricos y se componen de motores que contienen un elemento encerrojador externo denominado cerrojo de uña. El cruzamiento es el lugar donde se completa es el desvío y está compuesto de corazón, contracarriles y carriles exteriores, todos ellos dedicados a que el tren tenga la estabilidad necesaria para que se corte el carril de la vía directa y pase a utilizar el carril de la vía desviada. Ilustración 8. Composición de un aparato de vía. 32. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización se identifica la interrelación de los elementos del RAMS en los ferrocarriles, así como sus conceptos técnicos. Ilustración 13. Interrelación de elementos RAMS. En cuando a los conceptos técnicos de disponibilidad: ❖ Fiabilidad refereida a: o Todos los posibles modos de fallo del sistema en la aplicación y el entorno. o Frecuencia de ocurrencia o la probabilidad de cada modo de fallo. o Consecuencias de cada modo de fallo. ❖ Mantenibilidad referida a: o Frecuencia y tiempo para realización de mantenimientos preventivo y correctivo. o Tiempo para la detección e identificación de averías. o Tiempo para la restauración del sistema averiado. ❖ Explotación y mantenimiento referida a: o Todos los modos de explotación posibles y el mantenimiento requerido. o Factor humano o Herramientas, instalaciones y procedimientos para el mantenimiento efectivo. En cuanto los conceptos técnicos de seguridad: ❖ Todos los posibles accidentes y peligros asociados que pueden resultar de un fallo en el sistema, propiedades o características, en todos los modos de explotación, mantenimiento y condiciones del entorno. ❖ Características de cada peligro. ❖ Fallos relacionados con la seguridad referidos a: o Modos de fallo que pueden suponer un peligro o Frecuencia de ocurrencia o probabilidad de cada modo de fallo. o Secuencia y/o coincidencia de situaciones, fallos, estados de explotación, condiciones del entorno que pueden provocar un accidente. o Frecuencia de ocurrencia o probabilidad de situaciones, fallos, estados de explotación, condiciones del entorno relevantes. ❖ Mantenimiento de las partes del sistema relacionadas con la seguridad. ❖ Explotación del sistema y mantenimiento relacionadas con la seguridad referidas a: o Factores humanos. o Herramientas, instalaciones y procedimientos para el mantenimiento efectivo. o Controles y medidas eficaces para hacer frente a un peligro y mitigar sus consecuencias. 33. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización Como se puede extraer de los conceptos técnicos previamente desarrollados, la gestión de actividades de RAMS tiene un efonque basado en los riesgos, cuyo objetivo es identificarlos, derivar los requisitos y aplicar las medidas necesarias para evitar o controlar los riesgos identificados. La característica principal del enfoque basado en riesgos es el establecimiento de un criterio de aceptación de riesgos que está relacionado con la aceptabilidad de los riesgos residuales derivados de la aplicación de medidas de control. Es de vital importancia establecer correctamente el criterio de valoración de riesgos y de aceptación de los mismos para que el proceso de gestión del RAMS se realice de una forma exitosa. El criterio debe definirse en función de la definición del sistema. Se ha definito el criterio de aceptación del riesgo y su importancia, pero hasta ahora no se ha definido qué es un riesgo. Según la norma, es la combinación de dos elementos: ❖ La frecuencia prevista de ocurrencia de una pérdida. ❖ El grado de gravedad de dicha pérdida, o en otras palabras, la consecuencia. En este punto, cuando se hace referencia a la pérdida se debe entender como daños humanos, materiales y/o medioambientales, aunque estos últimos no se suelen incluir en los estudios de seguridad. Para realizar la reducción de los riesgos se debe seguir una estrategia, cuyo objetivo sea reducirlos hasta un nivel aceptable aquellos riesgos que se consideren como no aceptables. Inicialmente, el objetivo debería ser evitar el riesgo y si no fuera posible, se debe reducir la frecuencia al máximo posible. Si llegado a este punto no fuera suficiente, se debe minimizar la gravedad de las pérdidas. Los pasos necesarios para garantizar el diseño de los equipos y establecer las normas de explotación son los siguientes: ❖ Hacer que la función en consideración sea segura, es decir, diseñar el equipo en modo fail-safe, que quiere decir que, en caso de fallo, el sistema debe pasar a un estado más seguro. Como ejemplo se propone que en caso de emergencia el tren se detenga automáticamente. ❖ Proporcionar funciones de seguridad adicionales u otras medidas, si resulta necesario. ❖ Proporcionar información relacionada con la seguridad, si resulta necesario. Relacionado con este punto, se pone como ejemplo la inclusión de limitaciones temporales o permanentes a la explotación para garantizar la seguridad, como podría ser embridar una aguja para evitar circulación por una vía cortada. En la norma también se incluye la reducción de los riesgos relacionados con el RAM. Sin embargo, en este trabajo no se va a profundizar en exceso debido a que queda fuera del alcance. Algunas de las acciones para reducir los riesgos en cuanto a fiabilidad y disponibilidad son: ❖ Control del estado del sistema y del mantenimiento preventivo. ❖ Diseños que no exijan a los componentes un funcionamiento cerca de sus límites. ❖ Contar con sistemas redundantes. ❖ Contar con medidas para la explotación en modo degradado en caso de fallo. Una vez definida la base del proceso de gestión del RAMS, pasamos a detallar los requisitos generales de la gestión del RAMS en ferrocarriles. Ciclo de vida. El primer paso para identificar los requisitos generales es conocer ciclo de vida del sistema. 34. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización Ilustración 14. Ciclo de vida en V del proceso RAMS en ferrocarriles Se ha definido previamente la base sobre la que se sustenta el proceso RAMS, y en el el ciclo de vida se observan los tres bloques principales del proceso: ❖ Evaluación de riesgos, incluida la especificación de requisitos de RAMS. ❖ Implementación y demostración de que el sistema cumple con los requisitos especificados. ❖ Explotación, mantenimiento y retirada del servicio. Además de un flujo nominal entre las etapas del proceso, existen bucles de retroalimentación para incluir nuevos riesgos que puedan aparecer en etapas posteriores y para el control de los requisitos. El ciclo de vida se representa en V debido a que la rama descentente del lado izquierdo representa al desarrollo y la rama ascendente del lado derecho representa las actuaciones en campo. Las fases del ciclo de vida se describen detalladamente en el capítulo 7 de la norma CENELEC 50126, por lo que se entrará en detallé más adelante. Evaluación de riesgos. La evaluación de riesgos está directamente relacionada con la fase III, Análisis y valoración de riesgos, aunque como se ha puntualizado previamente, la evaluación de riesgos puede ser necesario en el resto de ciclo de vida. El proceso de evaluación de riesgos se muestra en la Ilustración 15, donde se distinguen dos pasos, análisis de riesgos y valoración de riesgos. 35. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización Ilustración 15. Proceso de evaluación de riesgos. Por definición, el análisis de riesgos es el uso sistemático de toda la información disponible para identificar peligros, las pérdidas potenciales relacionadas con dichos peligros y valorar los riesgos asociados. Se distingue entre los que necesitan un análisis en profundidad, es decir, son aceptables en términos generales y por tanto el análisis de riesgos conlcuye y los que no es necesario, por lo que no son aceptables en términos generales. Para estos últimos, el análisis de riesgos continúa aplicando un principio de aceptación de riesgos, que se dividen en tres posibles principios. ❖ Uso de un código de buenas prácticas. ❖ Comparación con un sistema similar como referencia. ❖ Estimación explícita del riesgo, sea cualitativa o cuantitativa. Tras la elección del principio de aceptación de riesgos, se continúa con la valoración del riesgo y la especificación de requisitos de seguridad. Para que un riesgo se considere admisible depende de los criterios de aceptación del riesgo establecidos por el marco jurídico o por el responsable del servicio ferroviario de acuerdo con lo que se establezca en el marco legal. Tareas de verificación y validación. La norma CENELEC 50126 establece las tareas de verificación para cada ciclo de vida, las cuales proporcionan las entradas de información para la validación. Su objetivo es la demostración del cumplimiento de los requisitos de cada fase del ciclo de vida. Las tareas de verificación deben comprender estos tres puntos: ❖ Exactitud y adecuación del análisis RAMS, cuando se especifique. ❖ Conformidad de los entregables de cada fase con los entregables de las fases anteriores. ❖ Adecuación de los métodos, herramientas y técnicas utilizados en cada fase, cuando se especifique. ❖ Exactitud, coherencia y adecuación de las especificaciones de las pruebas y de las pruebas ejecutadas, según corresponda. Es importante resaltar que los errores o deficiencias encontrados pueden requerir la reaplicación de algunas o todas las actividades de una o más fases anteriores del ciclo de vida hasta subsanarlo. Por el otro lado, las actividades de validación se llevan a cabo en dos fases del ciclo de vida: ❖ En la fase IV, Especificación de los requisitos del sistema, se tiene como objetivo garantizar que los requisitos del sistema se hayan especificado correctamente, aplicando los requisitos de las normas CENELEC y el resto de las normas de aplicación según el marco legal. ❖ En la fase IX, Validación del Sistema, se tiene como objetivo garantizar que se cumplen los requisitos especificados para la aplicación específica. Las partes interesadas que son responsables del proceso de validación a lo largo del ciclo de vida del 36. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización sistema debe quedar explícitamente definido para las actividades de validación, donde habitualmente para la fase IV es el responsable del servicio ferroviario y para la fase IX, el tecnólogo responsable del sistema de señalización. Para cada aplicación específica que comprenda un cambio significativo, se debe elaborar un plan de validación donde el alcance, los objetivos y las actividades de validación queden especificadas. Se entrará en el detalle del Plan de Validación en el capítulo 5.2. Evaluación independiente de la seguridad. La evaluación independiente de la seguridad es un medio para proporcionar confianza adicional en relación a la prevención de fallos sistemáticos del sistema en estudio que puedan afectar negativamente a la seguridad. Consiste en una evaluación y dictamen de que se han llevado a cabo los aspectos específicos del proceso de gestión de seguridad y que se han cumplido los requisitos específicos del sistema. Si bien, la norma CENELEC 50126 no define en qué situaciones es necesaria una evaluación independiente de la seguridad, sino que define los objetivos y requisitos aplicables en caso de realizarse. La entidad encargada de realizar esta evaluación debe elaborar un Plan de Evaluación Independiente que incluya el alcance de las actividades de evaluación independiente y su detalle a lo largo del proceso, los elementos de desarrollo que han de tenerse en cuenta, las declaraciones de aceptación y/o rechazo y las formas de tratar los casos de no conformidad y los requisitos relativos al contenido y forma de la documentación de evaluación independiente. Este plan se debe desarrollar utilizando la definición del sistema y la especificación de requisitos de este, proporcionados por el tecnólogo. Algunos puntos que debe cumplir la evaluación independiente de la seguridad son: ❖ Cumplir con el plan de evaluación independiente. ❖ Evaluar la conformidad del proceso y los resultados desarrollados. ❖ Identificar y evaluar cualquier desviación de los requisitos establecidos en la evaluación independiente. ❖ Emitir un juicio sobre la aceptabilidad de la justificación de la seguridad dado por el proyecto en el caso de seguridad, comprobando que las limitaciones pertinentes se tienen en cuenta en las SRACs y son suficientes para controlar los riesgos. ❖ Llevar a cabo inspecciones sobre el proceso global de desarrollo del sistema y posibilitar la solicitud de tareas adicionales de verificación y validación en el marco de evaluación independiente de la seguridad. Todas las actividades y los resultados de la evaluación independiente de la seguridad quedarán recogidos y registrados en el Informe de evalución independiente de la seguridad. Todos los sistemas, subsistemas o componentes que ya dispongan de una evaluación independiente de la seguridad, deben ser evaluados en su integración segura en el nuevo sistema en consideración. Esta evaluación es combinable con otro tipo de evaluaciones que sean requeridas por el marco legal. Por todo lo expuesto, los entregables principales de la evaluación independiente de la seguridad son los que se listan a continuación: ❖ Plan de evaluación independiente de la seguridad. ❖ Registro de los resultados de la evaluación independiente de la seguridad. ❖ Informe de la evaluación independiente de la seguridad. Fases del ciclo de vida RAMS. A continuación, se van a describir las fases del ciclo de vida, su objetivo, algunas actividades generales y tareas de seguridad que se deben realizar en ellas. 1) Concepto. Se deben establecer las características principales del proyecto, para garantizar un rendimiento adecuado de las actividades del ciclo de vida. Tarea de seguridad: Estudiar los requisitos previos de seguridad y rendimiento de seguridad en sistemas 37. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización anteriores, estudiar la legislación en materia de seguridad o definir el campo de aplicación de los requisitos de gestión de la seguridad para las siguientes tareas de seguridad del ciclo de vida. En los entregables se debe documentar e incluir todas las hipótesis y justificaciones extraídas de las actividades de esta fase. Los documentos asociados a esta fase se pueden encontrar en el Anexo I: Listado de Documentación. 2) Definición del sistema y contexto operativo. Se deben definir las características y funciones esenciales del sistema, las interfaces con otros sistemas, incluidas las entradas de información y los resultados previsibles y la organización para la gestión del RAM y seguridad del sistema. Algunas de las actividades de esta fase son: ❖ Establecer el objetivo del sistema y el perfil de su misión. ❖ Definir las fronteras del sistema, con el entorno físico, con otros sistemas tecnológicos, con seres humanos o con los responsables del sistema ferroviario. ❖ Establecer el campo de aplicación de los requisitos de explotación que influyen en el sistema, como las limitaciones de la explotación del sistema, el mantenimiento o la influencia de los seres humanos involucrados. ❖ Recoger las medidas de seguridad existentes y las hipótesis que delimintan la evaluación de riesgos. ❖ Identificar el sistema y los documentos relacionados. ❖ Crear una organización que asigne funciones y responsabilidades para la gestión de las tareas RAMS. ❖ Establecer un proceso de examen continuo para las cuestiones de seguridad y la comunicación de los requisitos pertinentes de seguridad del sistema entre las partes interesadas. En los entregables se debe documentar e incluir todas las hipótesis y justificaciones extraídas de las actividades de esta fase. Algunos documentos que son entregables de esta fase son: la definición del sistema, el plan RAM y el plan de seguridad. El resto de los documentos asociados a esta fase se pueden encontrar en el Anexo I: Listado de Documentación. 3) Análisis de valoración de riesgos. Se deben seguir los pasos para decidir si un riesgo es tolerable. Esta fase, pese a ser situada en el tercer escalón, es una fase continua en el tiempo. Algunas de las tareas de esta fase son: ❖ Identificar y clasificar los peligros asociados al sistema. ❖ Seleccionar los principios de aceptación del riesgo. ❖ Definir y aplicar los criterios de aceptación del riesgo. ❖ Evaluar los riesgos. ❖ Establecer un proceso para la gestión continua de los riesgos. En los entregables se debe documentar e incluir todas las hipótesis y justificaciones extraídas de las actividades de esta fase. El resto de los documentos asociados a esta fase se pueden encontrar en el Anexo I: Listado de Documentación. 4) Especificación de los requisitos del sistema. Se detallan los requisitos iniciales del sistema y los derivados de la fase anterior, evaluación de riesgos. Tarea de seguridad: establecer especificaciones de requisitos de seguridad, establecer condiciones de aplicación relacionadas con la seguridad o establecer un plan de validación de los requisitos. En los entregables se debe documentar e incluir todas las hipótesis y justificaciones extraídas de las actividades de esta fase. El resto de los documentos asociados a esta fase se pueden encontrar en el Anexo I: Listado de Documentación. 5) Arquitectura y asignación de los requisitos del sistema. Se asignan los requisitos a los diferentes 38. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización subsistemas. Si en esta fase del ciclo de vida se identificasen nuevos peligros, éstos se deben incluir en el registro de peligros previamente elaborado y se deben asignar al al subsistema correspondiente. En el caso en el que se utilice un subsistema preexistente, se debe asegurar que se cumplen todos los requisitos de la integración. Tarea de seguridad: realizar análisis de peligros o asignar los requisitos a los subsistemas y componentes. Además de actualizar la documentación de fases anteriores. En los entregables se debe documentar e incluir todas las hipótesis y justificaciones extraídas de las actividades de esta fase. El resto de los documentos asociados a esta fase se pueden encontrar en el Anexo I: Listado de Documentación. 6) Diseño e implementación. Se deben crear los subsistemas y componentes de acuerdo a los requisitos asignados y demostrar que éstos se cumplen. Para poder llevar a cabo el diseño y la posterior implementación, se deben elaborar diferentes procedimientos, en los que las fases de integración, explotación y mantenimiento deben ser tenidas en cuenta. Para ello, se elaboran los procedimientos de explotación y mantenimiento, formación para el personal, procesos de fabricación, procesos de integración y procedimientos de instalación y puesta en servicio. Algunas tareas de verificación de esta fase son: ❖ Verificación de cumplimiento de requisitos RAMS en el diseño. ❖ Verificación de cumplimiento del diseño de la implementación. ❖ Verficación de que los planes de fabricación producen elementos validados en cuanto a RAMS. ❖ Verificación de que todos los planes de actividades del ciclo de vida son coherentes de acorde a los requisitos. En los entregables se debe documentar e incluir todas las hipótesis y justificaciones extraídas de las actividades de esta fase. El resto de los documentos asociados a esta fase se pueden encontrar en el Anexo I: Listado de Documentación. 7) Fabricación. Se fabrican los subsistemas y componentes y se establecen y aplican los planes para garantizar el cumplimiento del RAMS. En esta fase se realizan tareas de verificación de informes de inspección y ensayos en el caso de que la fabricación sea del propio tecnólogo y de informe de garantía de la calidad en le caso de fabricación externa. En los entregables se debe documentar e incluir todas las hipótesis y justificaciones extraídas de las actividades de esta fase. El resto de los documentos asociados a esta fase se pueden encontrar en el Anexo I: Listado de Documentación. 8) Integración. Se montan e instalan todos los subsistemas y componentes y se demuestra que el sistema al completo funciona según lo definido en las interfaces. Todas las actividades de integración se deben llevar a cabo de acuerdo a la planificación de la integraciónEn el caso de introducir modificaciones o cambios en el sistema integrado, se debe disponer de un procedimiento de reversión, es decir marcha atrás, durante la integración. Además, se debe realizar un análisis de impacto para evaluar en qué medida se deben repetir las actividades del ciclo de vida anterior. Este punto se desarrollará más en profundidad en el apartado 0. En los entregables se debe documentar e incluir todas las hipótesis y justificaciones extraídas de las actividades de esta fase. El resto de los documentos asociados a esta fase se pueden encontrar en el Anexo I: Listado de Documentación. 9) Validación del sistema. Se valida el sistema, producto y los procesos para demostrar que cumplen con los requisitos RAMS junto con las medidas externas de reducción de riesgos para confirmar que es adecuado para el uso específico mediante exámenes y con la aportación de evidencias objetivas. 39. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización La principal tarea de seguridad sería la realización del informe de validación de la seguridad. Además, también se debe actualizar el informe caso de seguridad y el registro de peligros. En los entregables se debe documentar e incluir todas las hipótesis y justificaciones extraídas de las actividades de esta fase. El resto de los documentos asociados a esta fase se pueden encontrar en el Anexo I: Listado de Documentación. 10) Aceptación del sistema. Se comprueba que el sistema al completo cumple con el conjunto de requisitos RAMS y se acepta el sistema para su puesta en servicio. Tarea de seguridad: establecer un informe de evaluación independiente de la seguridad y asegurar la aprobación de las condiciones de aplicación relacionadas con la seguridad. 11) Explotación, mantenimiento y control del rendimiento del sistema. Se explota, mantiene y controla el sistema cumpliendo con los requisitos RAMS del sistema. Para ello se evalúa el rendimiento y se aplican medidas correctivas. El tecnólogo debe generar en las fases previas los planes y procedimientos necesarios para que el responsable ferroviario disponga de toda la información para mantener el cumplimiento de los requisitos RAMS. Esta información debe incluir todas las SRACs identificadas en el proceso. También se debe implementar un Sistema de Comunicación de Fallos y Medidas Correctivas (FRACAS). El proceso del FRACAS debe proporcionar información continua a todas las partes interesadas de cualquier fallo o defecto, y sus posibles causas, detectados durante el servicio. De igual forma que en la fase de Integración, se debe realizar un análisis de impacto de los fallos para evaluar en qué medida se deben repetir las actividades del ciclo de vida anterior. Este punto se desarrollará más en profundidad en el apartado 0. 12) Retirada del servicio. Se controla el riesgo durante la fase de transición. Entre las tareas de seguridad se incluye la identificación del impacto en la seguridad del cese del servicio y el desmontaje del sistema. Se debe asegurar que las instalaciones externas no queden afectadas de un modo inseguro. Por último, en la parte I de la norma CENELEC 50126, incluye un capítulo exclusivo al Informe Caso de Seguridad. Sin embargo, este documentó será analizado en profundidad en el capítulo 5.3. También se incluyen el anexo A y B destinados a aportar más información sobre el RAM, el cual queda fuera del alcance de este trabajo; el anexo C, destinado a los riesgos y sobre el que se profundizará más adelante; el anexo D, acerca de las directrices generales de la definición del sistema, sobre el que no se profundizará al no ser una tarea realizada por el equipo de seguridad; y el anexo ZZ, que relaciona esta norma y los requisitos esenciales de la directiva 2008/57/CE. Todos estos anexos son de carácter informativo. 3.2.2 Parte II En esta segunda parte de la norma CENELEC 50126 se definen las directrices generales y diferentes métodos que apoyan al Proceso de Gestión de la Seguridad descrito en la parte I de la norma. En el caso de elegir un método descrito en esta norma, los requisitos obligatorios para dicho método serán de carácter obligatorio. Evaluación de riesgos y control de peligros. Para realizar la descripción del método de evaluación de riesgos y control de peligros, la norma utiliza el modelo reloj de arena que proporciona una visión general y falicita la separación entre el análisis de riesgos como parte de la evaluación de riesgos y el análisis de peligros como parte del control de peligros. Mediante la evaluación de riesgos se obtienen los requisitos de seguridad para las cuestiones operativas y técnicas, donde se incluye el mantenimiento, mientras que mediante el control de peligros se controla el cumplimiento de los requisitos funcionales de seguridad mediante la determinación y el análisis de las causas y la concepción y aplicación de medidas de control. 40. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización Evaluación de riesgos. La evaluación de riesgos se realiza a nivel del sistema ferroviario y está basado en la definición del sistema e incluye el análisis y valoración de riesgos. Mediante el análisis de riesgos se definen los requisitos de seguridad de alto nivel del sistema, en particular desde el punto de vista del responsable del servicio ferroviario y del operador. Se incluye la identificación de peligros, análisis de las consecuencias y la selección del principio de aceptación del riesgo. La evaluación de los riesgos tiene los siguientes pasos: ❖ Realización de la evaluación de riesgos. La evaluación de riesgos se debe realizar con un nivel de detalle adecuado para permitir que se identifiquen los peligros con el conocimiento actual pero sin catalogar todos los peligros triviales. Si se considera útil, se deben correlacionar con los registros históricos de accidentes y los registros de las causas. Se debe realizar tomando el sistema como una caja negra y evaluando únicamente los límites. ❖ Resultado de la evaluación de riesgos. El resultado consiste en un conjunto de requisitos de seguridad asociados a funciones, sistemas o normas operativas claramente identificados. Estos requisitos pueden referirse a códigos de buenas prácticas, sistemas de referencia o dar objetivos concretos derivados de una estimación explícita del riesgo según el principio de aceptación del riesgo seleccionado. Los requisitos de seguridad incluyen funciones de seguridad, y éstas pueden ser evaluadas cuantitativamente, semicuantitativamente o cualitativamente. ❖ Control de peligros. El control de peligros garantiza que el sistema cumpla con los requisitos de seguridad. En esta fase, el diseñador del sistema se puede centrar en las causas internas de los peligros identificados. En esta fase también se realiza la tarea de identificación de peligros, pero se centra en las soluciones técnicas del propio sistema, es decir, la arquitectura definida y las interfaces internas, y no de sus funciones y el funcionamiento relacionado del sistema. ❖ Revisión de la evaluación de riesgos. Si durante la fase anterior no se consigue el cumplimiento de los requisitos de seguridad, se considera necesaria de una revisión de la evaluación de los riesgos. Esta situación se puede dar por tres causas: identificación de peligros adicionales a nivel del sistema, necesidad de nuevas normas de explotación o medidas de seguridad externas adicionales son requeridas para cumplir los objetivos de seguridad. ❖ Responsabilidades. La responsabilidad de la evaluación de riesgos recae sobre el responsable del servicio ferroviario y de los operadores de material rodante, si bien, la evaluación puede contratarse a otras partes siempre que se disponga de las competencias adecuadas. En cualquier caso, el responsable del servicio ferroviario debe aceptar los resultados de la evaluación de riesgos. Demostración y aceptación de la seguridad. Este capítulo de la norma pretender proporcionar detalles adicionales acerca de la demostración y aceptación de la seguridad, la cual se realiza mediante el Informe Caso de Seguridad. Éste se realiza para tres categorías diferentes: producto genérico, aplicación genérica y aplicación específica. Dado el alcance de este trabajo, nos centraremos en esta última, aunque la estructura del Safety Case sea la misma, que se detalla en la sección 5.3. En el Safety Case de la aplicación específica se deben incluir dos aspectos: diseño de la aplicación e implementación física. Éstos dos aspectos pueden se incluidos en un mismo documento o separados según la aplicación específica particular. Un safety case para un sistema puede depender de otro safety case de un subsistema y esta relación debe estar asociada a la descomposición del sistema definido en la fase II del ciclo de vida. En cualquier caso, para que se producza la aceptación del sistema general, se deben haber aceptado previamente los subsistemas existentes. En estos casos, es esencial que las SRACs de cada subsistema se cumplan en el safety case de nivel superior o bien, sean trasladadas a las SRACs del safety case de nivel superior. Un ejemplo de dependencias entre safety case puede ser cuando en una aplicación específica concurren la instalación de un nuevo enclavamiento y del sistema de protección ERTMS. 41. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización La aceptación del sistema como adecuadamente seguro para la aplicación prevista se debe realizar atendiendo a varias condiciones: ❖ Debe haber sido desarrollado, verificado y validado de acuerdo a las normas 50126 y sus requisitos se deben haber cumplido de acuerdo a las mismas normas. ❖ El conjunto de pruebas documentas debe comprender: la definición del sistema y contexto operativo, requisitos y características del sistema y análisis de riesgos cuando proceda, safety case e informe de evaluación independiente de la seguridad cuando sea necesario. Una vez que el sistema sea aceptado, en el caso en el que fuera necesario realizar una modificación se deberá realizar utilizando los mismos criterios de gestión de la seguridad de un nuevo diseño. Por ello, se debe actualizar el caso de seguridad y aportar la documentación adicional necesaria para la modificación, ya sea actualizando la documentación existente o generando nueva documentación. Durante el proceso de la modificación, el responsable ferroviario debe gestionar la seguridad continua del sistema. Organización e independencia entre funciones. La organización, funciones y responsabilidades del personal son factores clave para reducir los fallos sistemáticos que se deben tener en cuentas durante el ciclo de vida del sistema. Se debe distinguir entre las primeras fases del ciclo de vida, de la I a la IV, y el resto de fases del ciclo de vía, ya que al ser las funciones realizadas dichas fases diferentes, las personas responsables pueden cambiar. La distinción aplica igualmente ocurre con el evaluador independiente. Un requisito obligatorio que establece la norma es la implantación de un proceso para la organización y gestión del personal y responsabilidades equivalente a lo establecido en la Norma EN ISO 9001. En las fases iniciales del ciclo de vida, de I a IV, se presta atención únicamente a los fallos sistemáticos. Para su prevención se toman medidas de control y la posterior corrección cuando aplique. Entre las medidas de control se encuentra la verificación de los resultados al final de cada ciclo de vida, la cual debe ser realizada por una entidad que no haya participado en las funciones de elaboración de los resultados. Así mismo, los requisitos de seguridad deben ser validados y ésta funciones debe ser independiente del director del proyecto. En estas fases el Verificador y el Validador pueden ser la misma persona pero, en ese caso, deben ser independientes del Project Manager. En la Ilustración 16 se muestran las dependencias e independencias en esta fase: Ilustración 16. Organización y dependencias en las fases inciales del ciclo de vida. En las fases posteriores del ciclo de vida, desde la V en adelante, el verificador y el validador no deben haber participado en el diseño en ninguna de las fases iniciales, ni en la especificación de requisitos, pero sí pueden identificar la falta de requisitos de seguridad y participar en la especificación de requisitos. Tras los resultados de la evaluación de riesgos de la fase III, se pueden dar dos alternativas: en el caso A se mantiene la misma estructura de independencia de las fases iniciales, ya que es la más restrictiva y siempre está permitida; mientras que en el caso B, se reduce la estructura de independencia, siempre a condición de que los resultados del análisis de riesgos no demuestren posibilidades directas de víctimas mortales o que el nivel de integridad de seguridad sea inferior o igual a SIL2. En el caso B, tanto el validador como el verificador pueden estar bajo el control del director del proyecto. 48. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización El verificador es el responsable de redactar el Plan de Garantía de Calidad del software, que debe ser específico para el proyecto e incluir al menos los siguientes puntos: ❖ Definición del modelo del ciclo de vida incluyendo las actividades y tareas básicas compatibles con los planos, los criterios y las propias entradas y salidas de cada actividad, las principales actividades de calidad y la entidad responsable de cada actividad. ❖ Estructura de la documentación. ❖ Control de la documentación relativo a los roles de los implicados en su redacción, control y aprobación, el campo de aplicación de la distribución y el archivo. ❖ Seguimiento y trazabilidad de las desviaciones. ❖ Métodos, medidas y herramientas para la garantía de calidad en función del nivel SIL. ❖ Justificaciones de que cada combinación de técnicas o medidas seleccionadas es apropiada para cada nivel SIL del software. Si alguno de estos puntos se define en otro documento, se deberá indicar en el Plan de Garantía de la Calidad del software la referencia del documento donde se incluye la información. Además, en el plan se deben recoger todas las referencias a las actividades definidas en la norma y resumidas en este punto. Por último, en el plan se debe especificar los detalles de su actualización durante el proyecto, como por ejemplo, la frecuencia, el responsable o el método. El verificador también deberá redactar el Informe de Verificación de la Garantía de la Calidad del Software y en él se debe incluir que el plan cumple con los requisitos generales de legibilidad y trazabilidad, así como con la coherencia interna. También debe incluir los resultados de las actividades descritas en el plan. En esta tarea también se define el Sistema de Gestión de la Configuración, el cual debe abarcar el control de gestión de la configuración, mediante el que se gestionan las autorizaciones y registros de las modificaciones, el entorno de desarrollo del software utilizado durante el ciclo de vida completo o la trazabilidad a los requisitos. Modificaciones y control de las modificaciones. El objetivo de eta tarea es garantizar que el software siga funcionando como se requiere cumpliendo en nivel de integridad de la seguridad y la fiabilidad de funcionamiento cuando sea modificado. El encargado de este conseguir este objetivo es el Gestor de Configuración. Para ello, los documentos de entrada son el Plan de Garantía de Calidad del software, el Plan de Gestión de la Configuración del sotfware, cualquier documento pertinente de diseño, desarrollo y análisis, las solicitudes de modificación y el análisis de impacto y la autorización de las modificaciones. Tras llevar a cabo la tarea, los documentos de salida serán aquellos documentos de entrada que hayan sido modificados, los registros de modificaciones del software y los registros de la nueva configuración. Los aspectos mínimos que se deben definir en el Proceso de Gestión de las Modificaciones se resumen en los siguientes puntos: ❖ Documentación necesaria para informar de un problema y/o adoptar acciones correctivas. ❖ Análisis de la información recogida en los informes de problemas para identificar sus causas. ❖ Prácticas a seguir para informar, seguir y resolver problemas identificados durante la fase de desarrollo y mantenimiento del software. ❖ Responsabilidades organizativas específicas en relación al desarrollo y mantenimiento del software. ❖ Método para aplicar controles con el objetivo de garantizar que las acciones correctivas adoptadas son efectivas. ❖ Análisis de impacto del efecto de las modificaciones sobre el componente software que se encuentre en desarrollo o entregado. ❖ En el análisis de impacto se debe indicar la re-verificación, re-validación y re-evaluación necesarias para la modificación. 49. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización ❖ En caso de múltiples modificaciones, el impacto acumulado debe ser tenido en cuenta en el análisis de impacto. ❖ Autorización antes de la implementación. Implantación y mantenimiento del software. El objetivo de esta tarea es garantizar que el software funciona según lo requerido, preservando el nivel SIL y la fiabilidad cuando se implanta en el entorno final de la aplicación específica. Esta tarea es responsabilidad del jefe de proyecto. En cuanto a los documentos de entrada, para esta tarea se requiere todos aquellos documentos de diseño, desarrollo y análisis pertinentes para la implantación. Los documentos de salida de la tarea son la versión del software publicado y el Plan de Implantación, el Manual de Implantación del software, las Notas de la Versión Publicada, los Registros de la Implantación y el Informe de Verificación de la implantación. Previo a la liberación de una nueva versión de software, se debe actualizar la línea base del software y mantener trazable bajo el control de gestión de la configuración. Además, se debe incluir el software anterior y también si hubiera alguna versión desarrollada con una versión anterior de esta norma. Esta versión nueva debe ser reproducible durante el ciclo de vida de la línea base. El Diseñador es el responsable de redactar la Nota de la Versión Publicada y en ella se deben definir las condiciones de aplicación que se deben cumplir, la información de compatibilidad entre componentes software y entre componente softwar y hardware y las restricciones de uso del software. El Manual de Implantación del software debe ser redactado utilizando los documentos de entrada de esta tarea y debe definir los procedimientos necesarios para identificar e instalar correctamente la nueva versión de software publicada. Cuando una nueva versión sea instalada, se debe contar con un procedimiento de reversión para volver a la versión anterior. También se debe contar con un mecanismo de autoidentificación para poder identificar la versión del software, cualquier dato de configuración o la identidad del producto durante y después de la carga. El Registro de Implantación debe hacer uso de los mecanismos de autoidentificación para demostrar que el software cargado es el realmente previsto. Estos registros forman parte de la fase de puesta en servicio y aceptación y se debe almacenar con los otros documentos relativos al sistema entregado. El software implantado de poder ser trazado en todas aquellas instalaciones en las que haya sido entregado y debe proporcionar información de diagnóstico como parte del control de errores. En el Informe de Verificación de la Implantación, el verificador debe incluir el cumplimiento de los requisitos generales de legibilidad y trazadabilidad y la coherencia interna del Manual de Implantación del software, del Registro de Implantación y de la Nota de la Versión Publicada. Otras secciones que se incluyen en la Norma, pero en las que no se va a profunidzar en este trabajo son el Mantenimiento del software, las Herramientas de soporte y lenguajes, Desarrollo del software genérico o Desarrollo de los datos o algortimos de aplicación. Los anexos de esta norma son de carácter informativo y amplían la información incluida en los capítulos ya descritos, pero no se profundizará en ellos. Los anexos tratan sobre el Criterio para la selección de técnicas y medidas, los Roles principales y responsabilidades relativas al software, un Resumen del control de los documentos y la Bibliografía de las técnicas. 50. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización 3.4 CENELEC 50129 La norma CENELEC 50129 está enfocada en definir las evidencias necesarias para que el sistema ferroviario relacionado con la seguridad, en el campo de la señalización, sea aceptado. Define las actividades que es necesario llevar a cabo tanto antes de la fase de aceptación del sistema, como después. Por ello, el título de la norma es CENELEC 50128. Aplicaciones ferroviarias. Sistemas de comunicación, señalización y procesamiento. Sistemas electrónicos relacionados con la seguridad para la señalización. Esta norma está publicada desde el año 2018, sustituyendo a su anterior versión del año 2003. El fundamento del trabajo que realiza el ingeniero de seguridad está basado en esta norma ya que en ella se establecen las evidencias necesarias para que un sistema de señalización sea aceptado. Esta norma aplicará a todos aquellos sistemas o subsistemas de nueva creación tras la publicación de la norma y a aquellas modificaciones de lo existente. Como en las normas anteriormente descritas, se va a realizar un resumen de los principales capítulos de la norma y, en este caso, de algunos anexos de especial interés. Requisitos para el desarrollo de sistemas electrónicos relacionados con la seguridad. Para que un sistema, subsistema o equipo sea considerado seguro se deben cumplir tres grandes condiciones en su aplicación prevista: el cumplimiento de los requisitos del proceso de gestión de la calidad y de la seguridad y el cumplimiento de los requisitos funcionales y técnicos y contrar con las evidencias técnicas de la seguridad del diseño. En cuanto al proceso de gestión de la calidad queda definido en la primera parte de la Norma 50126-1 y su cumplimiente proporciona la primera condición para la aceptación de la seguridad. Por otro lado, el proceso de gestión de la seguridad se debe aplicar a todos los sistemas y subsistemas relacionados con la seguridad, pero adaptándolo al nivel de integridad de la seguridad, y su cumplimiento supone la segunda condición para la aceptación de la seguridad. En el contexto del proceso de gestión de la seguridad se proporcionan unas directrices para estructuras la documentación, ya que es esencial que la documentación sea precisa, clara y completa para que se garantice la verificación de las evidencias de seguridad. Algunas de estas directrices son las siguientes: ❖ Especificación de un plan de documentación. ❖ Lista de comprobación de los contenidos de los documentos. ❖ Determinación de la forma del documento. ❖ Gestión de la documentación. Algunas de las medidas que facilitan la obtención son la definición de plantillas normalizadas, agrupación de la documentación de acuerdo al ciclo de vida, disponibilidad de análisis de impacto en caso de modificación o evitar las redundancias. Además, los documentos relacionados con la seguridad deben clasificarse acorde a los requisitos de confidencialidad. Otros puntos ya definidos en la norma 50126, son incluidos en este capítulo, como el ciclo de vida, la independencia de funciones, el plan de seguridad, el registro de peligros, la especificación de los requisitos de seguridad o el diseño del sistema de la seguridad, este último también explicado en la norma 50128. Dentro de las actividades del proceso de gestión de la seguridad se incluye el plan operativo y de mantenimiento de la seguridad, el cual se realiza con el objetivo de garantizar el funcionamiento correcto y seguro del sistema en las condiciones ambientales especificadas y en el que se documentan las regulaciones, condiciones y limitaciones para el control operativo de la seguridad. Como se ha venido desarrollando en el resumen de las normas, unas de las tareas principales del ingeniero de seguridad son la verificación de la seguridad y la validación de la seguridad y para ello, se deben realizar los respectivos informes de verificación y validación. Otra de las actividades a realizar en el proceso son los ensayos de calificación de la seguridad, cuyos objetivos son aumentar la confianza en que el sistema cumple con los requisitos de explotación especificados, que se alcanzan los objetivos de fiabilidad y seguridad o permitir la puesta en servicio de los sistemas antes de la aprobación final de la seguridad con la condición de tomar las medidas y el control adecuado. El alcance de 51. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización los ensayos debe ser acordado entre la autoridad ferroviaria y el tecnólogo en particular, y se justifica mediante el grado de complejidad del sistema. Estos ensayos se deben completar antes de la puesta en servicio y durante el proceso en el que son llevados a cabo, la seguridad no está plenamente garantizada, por lo que se deberán tomar las medidas adecuadas para controlar los posibles peligros. Una vez sean realizados los ensayos, se debe elaborar una declaración donde se especifiquen las condiciones de explotación del sistema y el nivel de autorización obtenido. La actividad más importante y sobre el que se fundamenta todo el trabajo del ingeniero de seguridad es la gestión de las condiciones de aplicación relacionadas con la seguridad. El objetivo de una SRAC es establecer las hipótesis y condiciones necesarias para mitigar los riesgos en la integración del sistema específico en un sistema global y por ello, su cumplimiento y demostración es una condición previa para una integración segura. Las SRACs deben ser transmitidas al usuario final y para evitar un esfuerzo innecesario en el tratamiento de las SRACs, se deben considerar algunas buenas prácticas como evitar declarar las SRACs que no lo son o que podrían haber sido evitadas en el diseño, evitar SRACs cuya información no esté completa, sea errónea, no esté redactada de forma clara o cuya aplicación no sea posible o razonable. Dada la definición de SRAC, éstas deben estar vinculadas al menos a un peligro y si se identifican peligros en etapas avanzadas del ciclo de vida, se debe crear una SRAC cuando no se pueda cumplir completamente un requisito de seguridad. Por último, en el proceso de gestión de la seguridad también se incluye la evaluación independiente de la seguridad. Requisitos para elementos que siguen diferentes ciclos de vida. Existen elementos de apoyo que no siguen el ciclo de vida de la seguridad y que pueden influir en la seguridad funcional. La seguridad del sistema se puede basar en sus propiedades específicas, pero para ello, estos elementos deben encuadrarse en alguna de las siguientes tres categorías: ❖ Uso de sistemas preexistentes que hayan sido desarrollados y no puedan ser modificadors para el sistema en estudio. ❖ Herramientas que se utilicen de forma independiente respecto al sistema estudiado. ❖ Seguridad informática gestionada en su propio marco. Comenzando por el uso de elementos preexistentes, en esta norma los elementos son considerados como tal cuando son complejos y no han sido desarrollados de acuerda a esta norma, incluyendo todas sus versiones. Algunas de la deficiencias detectadas en los elementos preexistentes son la falta de pruebas realizadas o documentadas sobre procesos relacionados con la gestión de la calidad y la gestión de la seguridad o que no se puede garantizar la ausencia sufientes de averías sistemáticas al no haber sido realizadas orientadas a la seguridad funcional, y por otro lado, la falta de pruebas técnicas, donde se incluyen la falta de pruebas realizadas o documentadas, propiedades o funcionalidades desconocidas y falta de diseño orientado a la seguridad. La reutilización de estos elementos no es eficaz debido a que su demostración de la seguridad puede ser más tediosa. Sin embargo, existen dos tipos de elementos para los que sí es eficaz su reutilización: aquellos sistemas completos que hayan sido desarrollados acorde a otras normas de seguridad y los equipos preexistentes que solo realicen una parte de la función relacionada con la seguridad. Los requisitos necesarios para los primeros son la identificación de las evidencias existentes, subsanación de los problemas identificadas de conformidad con los requisitos de la norma 50129 y en caso de ser un SIL superior al nivel básico, realizar una evaluación independiente para garantizar las medidas aplicadas. Para los segundos tipos de elementos preexistentes los requisitos mínimos son: ❖ Disponer de una información mínima como funcionalidad, interfaces, restricciones, tasa de fallos o condiciones ambientales y de uso. ❖ Inclusión del equipo en la definición global del sistema y ponerlo en modo de control de la configuración ❖ Identificación de los modos de fallos funcionales peligrosos y para cada uno o bien demostrar que dicho modo de fallo no puede producirse de forma creíble, proporcionar una demostración de 52. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización seguridad completa de acuerdo al SIL requerido o negar el modo de fallo de forma externa y aplicar un estado segurido. ❖ Para cualquier equipo con función SIL, se debe demostrar que la tasa de fallos total del equipo es compatible con la tasa de fallo funcional tolerable para la función completa, siempre que no se pueda identificar el componente particular del equipo que contribuya al peligro. ❖ Todas las actividades de diseño, verificacación y validación de la seguridad y evaluación se debe realizar englobando el equipo preexistente como una caja negra. ❖ Definir una estrategia para gestionar los efectos de los cambios de producto, para todos los SIL. Para la segunda categoría, las herramientas utilizadas de forma independiente se tratan de las herramientas utilizadas en cualquier de las fases del ciclo de vida y que generan resultados contribuyendo al diseño o implementación y cuyos errores podrían conducir directamente a una avería sistemática peligrosa. Estas herramientas afectan directamente a la seguridad. También pueden afectar indirectamente si sus errores afectan a la detección de otros errores de otras fuentes. En el caso de las herramientas de soporte del desarrollo de software están cubiertas por la norma 50128 y quedan fuera del alcance de esta norma. En el caso de las herramientas que pueden afectar directamente a la seguridad, se deben tener en cuenta algunos requisitos: ❖ Se debe aplicar a estas herramientas la tarea de identificación y análisis de peligros. ❖ En la validación de seguridad de cualquier producto genérico o aplicación genérica o específica se debe confirmar que las herramientas y procesos relacionados con la seguridad cumplen con los requisitos en todas las actividades del ciclo de vida. ❖ Seguir al menos una de las técnicas entre la verificación de los resultados de la herramienta, herramienta validada en uso, herramienta validada mediante análisis y ensayos, diversidad de las herramientas o herramienta con SIL adecuado. Para la tercera categoría, seguridad física e informática, existen dos tipos de amenazas derivadas del acceso no autorizado a los equipos de señalización, aquellas relacionadas con la seguridad física que pueden producir peligros para la seguridad funcional, y aquellas relacionadas con la seguridad informática, donde se puede afectar a la seguridad de los equipos de señalización mediante acceso lógico. Para gestionar este último tipo de amenazas, en esta norma no se proporcionan requisitos específicos aunque existen varias normas que ofrecen indicaciones, como la Norma ISO 27000ff, el Informe Técnico ISO/IEC/TR 19791 o la serie de normas IEC 62443. Estas amenazas se deben gestionar en la etapa de evaluación de riesgos y control de peligros. Por otro lado, las medidas que gestionen las amenazas de seguridad pública se deben incluir en el Safety Case. En esta norma también se detalla la estructura del Safety Case, sin embargo, se va a detallar en el capítulo 5.3. Aceptación de la seguridad del sistema y fases posteriores. En este último capítulo de la norma se profundiza acerca de las últimas etapas del ciclo de vida, donde se produce la entrega del sistema, subsistema o equipo por parte del tecnólogo al responsable del servicio ferroviario y para ello se deben cumplir sus requisitos. Las evidencias documentales para realizar la aceptación de la seguridad es la especificación de los requisitos del sistema, los resultados de la evaluación de riesgos, la especificación de los requisitos de seguridad, el caso de seguridad y el informe de evaluación independiente de la seguridad. Cumpliendo con todas las condiciones de aceptación y con el resultado favorable de la evaluación independiente, el responsable ferroviario considerará el sistema aceptable en relación a la seguridad. En ciertos casos, pueden ser posible medidas adicionales impuestas por el marco legal. En los casos en los que se utilice un producto o aplicación genérica en el contexto de una aplicación específica, la aceptación de la seguridad se realizará mediante el informe de evaluación independiente de la seguridad existente, lo que se denomina aceptación cruzada. En la etapa de explotación, mantenimiento y control del funcionamiento del sistema, se deben respeta lo 53. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización definido en el plan de explotación y mantenimiento. En él quedan definidos los procedimientos, sistemas de apoyo y supervisión de la seguridad adecuados para la explotación segura y continua durante toda la vida útil. En el caso en el que se pretenda realizar una modificación, se debe evaluar su impacto en la seguridad y en caso de posible impacto, se debe realizar aquella parte del ciclo de vida de seguridad que corresponda. En el final de la vida útil se deben llevar a cabo las medidas necesarias que se indiquen en el Safety Case y que deben ser incluidas en los manuales de mantenimiento. En esta norma también se incluyen algunos anexos de carácter normativo, como los niveles de integridad de seguridad, la gestión de averías para funciones relacionadas con la seguridad, la identificación de los modos de fallo de los componentes hardware o la técnicas y medidas para la prevención de averías sistemáticas y el control de averías aleatorias y sistemáticas. También se incluyen otros anexos de carácter informativo. 54. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización 4 METODOLOGÍA DE UN PROYECTO DE SEÑALIZACIÓN FERROVIARIO Tras la revisión de la normativa que rige los proyectos del subsistema CMS en el ámbito ferroviario, se va a profundizar en todas las actividades que un ingeniero de seguridad ferroviaria debe abordar para seguir el ciclo de vida definido en la normativa CENELEC previamente resumido. Las etapas que a continuación se describirán conforman una metodología de trabajo para un proyecto considerado como grande, es decir, una renovación de la señalización de una línea, una nueva línea o la implantación de una nueva tecnología. Para los proyectos más pequeños como las actuaciones de mantenimiento, generalmente no se abordan todas las etapas. Esta metodología está extraída de la experiencia del autor en la materia, si bien no es una metodología cerrada, por lo que podrán existir más o menos etapas según el proyecto que se realice. Por norma general, se han identificado 16 etapas o actividades, para completar el ciclo de vida del proyecto. En ellas se realizará una breve descripción de las características de la etapa, las responsabilidades del ingeniero de seguridad y el momento temporal del proyecto en el que se lleva a cabo. I. Etapa de licitación del proyecto y contratos. La primera etapa de un proyecto es la licitación y la redacción del contrato entre el responsable ferroviario que pretende realizar el proyecto y el técnologo que se encargará de realizar los trabajos. En este momento debe quedar definido el tipo de proyecto a realizar, ya sea de renovación, modificación y/o mantenimiento o nueva línea, y los equipos que se desean instalar en el ámbito del proyecto. Además, también se comienza la gestión económica del proyecto y se establece la duración prevista del mismo. La responsabilidad de llevar a cabo esta etapa suele recaer en el Project Manager y por tanto, no está involucrado el ingeniero de seguridad. Esta etapa queda fuera del ciclo de vida de seguridad. II. Elaboración del Concepto y Definición del sistema y Plan de Pruebas y Puesta en Servicio. Una vez ha comenzado oficialmente el proyecto tras la firma de los contratos, nos introducimos en las primeras etapas del ciclo de vida. En la práctica, las etapas I y II habitualmente se realizan en paralelo y por ello se realiza el documento de Concepto y Definición del sistema. El documento de Concepto y Definición del sistema pretende recopilar todo aquello que se ha negociado e incluido en el contrato, con el objetivo de recoger en un documento todo aquello que debe contener el subsistema de señalización en la aplicación específica, lo que incluye el listado de equipos, las versiones de los productos genéricos o las interfaces con elementos internos y externos. Este documento debe ser realizado por el TPL o líder técnico del proyecto, o en su defecto, por el Project Manager. Habitualmente los proyectos grandes donde se construye o renueva una línea completa, o un gran tramo de una línea, se subdividen en varias fases. Por ello, en paralelo a la elaboración del Concepto y Definición, la técnica Test and Commissioning se debe encargar de elaborar el documento de Plan de Pruebas y Puesta en Servicio en el que se deben establecer todas las fases del proyecto y se deben definir qué elementos se instalan y se ponen en servicio en cada momento. Además, también se incluyen las pruebas que son necesarias para garantizar la seguridad del sistema de acorde a la normativa de aplicación, y se definen aquellas restricciones necesarias para las puestas en servicio parciales. La calidad y precisión de la información descrita en estos documentos es fundamental para sentar las bases correctas del resto del proyecto. En el caso en el que la información no sea de alta calidad, es decir, que se proporcionen los detalles necesarios y suficientes, o no sea precisa, conteniendo contradicciones entre documentos o información errónea, la probabilidad de que se comentan errores que se arrastren a lo largo del proyecto afectando en tiempo y/o coste es considerable. Una vez que estos documentos han sido realizados, el ingeniero de seguridad está en disposición de comenzar su trabajo en el proyecto. En la sección anterior, del resumen de la normativa CENELEC, se ha 55. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización destacado que las tareas que realizan los ingenieros de seguridad se concentran principalmente en la fase IX, Validación del sistema. Sin embargo, su participación es fundamental en todas las fases del ciclo de vida y comienza por la verificación de los documentos objeto de este punto, y dada la importancia de estos documentos, la revisión de los mismo por parte del ingeniero de seguridad es la primera tarea que debe ser realizada. Los dos próximos puntos que a continuación se van a desarrollar, cronológicamente pueden realizarse en el mismo tiempo, si bien nos forman parte de la misma fase del ciclo de vida. III. Elaboración de planes. La primera de las dos actividades que coinciden en el tiempo es la elaboración de los planes del proyecto. En el título de la actividad “Elaboración de planes” se pueden englobar todos los planes del proyecto, y teóricamente, todos ellos deben realizarse en esta fase. Sin embargo, en la práctica no todos son realizados en este momento temporal del proyecto, y por ello, nos centraremos en aquellos que sí se realizan en este punto. Los principales planes elaborados en este momento temporal del proyecto son los Planes de Seguridad, de Verificación y Validación, de Calidad, de Gestión de Requisitos, o los planes de preparación de la aplicación que se realizan para todas las aplicaciones software, como el enclavamiento o el sistema videográfico. Los planes de seguridad y de verificación y validación son los que se realizan por los ingenieros de seguridad, y en ellos se definen todas las actividades a desarrollar en el transcurso del proyecto. Se profundizará sobre ellos en los apartados 5.1 y 5.2. Para el resto de los planes, cada técnica es responsable de realizar su plan siendo el departamento de calidad el responsable del Plan de Calidad; la técnica de enclavamiento, la responsable del Plan de Preparación de la Aplicación IXL; o la técnica de centros de control, la responsable del Plan de Preparación de la Aplicación CTC y/o PLO. De la misma forma que con los documentos de las actividades anteriores, el ingeniero de seguridad es el encargado de revisar estos planes y asegurar que cumplen con los objetivos de la verificación. Otros planes que deben ser realizados pero que habitualmente se realizan en momentos temporales posteriores son el Plan de Operación y Mantenimiento, como ejemplo de momento posterior, o el Plan de Pruebas y Puesta en Servicio, como ejemplo de momento anterior. IV. Análisis Preliminar de Riesgos y/o Declaración de Riesgos Previa. La segunda de las actividades que es habitual llevar a cabo en conjunto con los planes es el Análisis Preliminar de Riesgos y/o la Declaración de Riesgos Previa. Ambos documentos tienen un objetivo similar, el cual es obtener todas aquellas amenazas que son susceptibles de ocurrir en el sistema por el hecho de utilizar unos productos genéricos en la aplicación específicas. El proceso que es necesario seguir para obtener este objetivo es la actividad definida en la normativa como Evaluación de Riesgos. Por tanto, esta actividad se enmarca en la fase III del ciclo de vida del proyecto, Análisis y Valoración de Riesgos. La metodología seguida para realizar esta actividad es la siguiente: 1. Clasificación de los posibles accidentes comúnmente aceptados, que son susceptibles de ocurrir durante la explotación ferroviaria, entre colisión, descarrilamiento y atropello. 2. Detallar las consideraciones a tomar para realizar la evaluación de riesgos. 3. Plantear la situación inicial y listar las actuaciones que se llevarán a cabo por el tecnólogo. 4. Descripción de las amenazas y análisis de la medida de mitigación. 5. Evaluación del riesgo inicial y del riesgo resultante tras la aplicación de la medida de mitigación. La principal diferencia entre ambos documentos reside en el proyecto en el que se realizan. El Análisis Preliminar de Riesgos (PHA, por sus siglas en inglés Preliminary Hazard Analysis) generalmente se realiza en proyectos de gran envergadura donde el objetivo es la construcción de una nueva línea o la renovación de la señalización de una línea existente. Estos proyectos se dividen en múltiples fases y este análisis se realiza a nivel general de proyecto, analizando las amenazas derivadas de los productos genéricos a suministrar. 56. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización Por otro lado, la Declaración de Riesgos Previa (DRP) está relacionada con la puesta en servicio y con las actividades particulares que por realizar una modificación en concreto son necesarias realizar. Por ello, este segundo análisis es habitual realizarlo en proyectos de menor envergadura que consistan en modificaciones puntuales. Si la circulación en la estación sobre la que se va a realizar la modificación se corta completamente, entonces generalmente no es necesario realizar este documento. Como ejemplo de diferencia entre ambos análisis, es la amenaza surgida por la embridación de una aguja para evitar la circulación de trenes en una vía en concreto. Esta amenaza sí formaría parte de la DRP y no formaría parte del PHA. Por último, ambos documentos son realizados por el ingeniero de seguridad. V. Identificación y evaluación de requisitos Los requisitos del proyecto provienen principalmente de la documentación contractual del proyecto, ya que en función de los productos contratados se establecen los principales requisitos. Además, según la experiencia del cliente, las condiciones del entorno en el que se realice el proyecto o las protecciones extra que se quieran implementar, se incluyen el resto de los requisitos de funcionalidad que deben desarrollar los productos. Por último, a raíz de la identificación y evaluación de riesgos se extraen más requisitos de seguridad. La actividad Identificación de requisitos se realiza tras concluir con la evaluación de riesgos de la actividad anterior, por lo que, si bien no coinciden temporalmente, ésta es inmediatamente posterior. En esta tarea, el ingeniero de seguridad debe comprobar la correcta trazabilidad de los requisitos y comprobar que los requisitos finales del proyecto vengan de los requisitos generales aguas arriba extraídos de los contratos con el objetivo que los requisitos no sean erróneamente asociados a productos que no le aplique. Además, se deben categorizar aquellos los requisitos entre los de seguridad y los de no seguridad. Otra de las tareas del ingeniero de seguridad es comprobar la correcta trazabilidad de los requisitos finales con las pruebas de laboratorio, para asegurar que todos aquellos requisitos de seguridad tengan una prueba de laboratorio asociada. VI. Gestión de la documentación de entrada. Tras superar la fase V del ciclo de vida del proyecto, Arquitectura y Asignación de los requisitos del sistema, nos adentramos en la fase del ciclo de vida que mayor cantidad de recursos consume a lo largo del proyecto, es decir, la fase VI, Diseño e Implementación. Sin embargo, antes de comenzar a realizar el diseño de la integración de los productos genéricos del tecnólogo en la aplicación específica, se deben identificar aquellas bases de diseño que el administrador ferroviario proporciona. Estas bases de diseño varían notablemente según varía el administrador en cuestión. Cuando el administrador no tiene la capacidad técnica suficiente para elaborar unas bases de diseño que sean ampliamente reconocidas por sector ferroviario, habitualmente se apoya en la know-how del tecnólogo. En el proyecto en el que se dé el caso contrario, se utilizarán estas bases de diseño. Un administrador ferroviario ampliamente reconocido en el mundo ferroviario es Adif y su conjunto de normativa técnica. Adicionalmente a la base de diseño que proporcione el administrador ferroviario, existen dos documentos que son clave en el diseño y que pueden ser proporcionados tanto por el administrador como diseñado por el tecnólogo: la tira de vía y el programa de explotación (PEX). Antes de comenzar el diseño se debe tener claro quién proporciona estos dos documentos que son la entrada al resto del diseño. VII. Gestión de la documentación de diseño. Tras la determinación de quién es el proveedor de la tira de vía y del programa de explotación, todas las técnicas podrán comenzar a elaborar sus diseños y la documentación asociada a ellos. La responsabilidad de llevar a cabo la fase es, por tanto, de todas las técnicas debido a que son los encargados de realizar el diseño, pero también de los ingenieros de seguridad ya que se debe revisar toda la documentación generada, para garantizar que se cumplen los objetivos de la verificación. A continuación, vamos a realizar un breve recorrido por todas las técnicas involucradas en esta actividad. 57. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización Documentación de Enclavamiento. La técnica de Enclavamiento es la encagada de realizar el software que permita el control de la señalización por parte del enclavamiento. Para realizarlo, se debe nutrir de diversa documentación entre las que se encuentran los dos principales, la tira de vía y el programa de explotación, ya que del primero se extrae la localización de los diferentes elementos de señalización en las vías, y del segundo se obtiene la información de todas las posibles rutas y las protecciones necesarias para evitar colisiones. Otra documentación necesaria para realizar el software son los requisitos funcionales del enclavamiento o los planos de conexiones y de bastidores del enclavamiento. En el caso en el que el programa de explotación no sea un documento de entrada al proyecto, es el tecnólogo y, por tanto, la técnica de enclavamiento, el encargado de realizarlo. También debe involucrarse el ingeniero de seguridad, ya que el programa de explotación debe ser revisado para asegurar que se cumplen con todos los requisitos del enclavamiento. Una vez se ha realizado el software, la técnica de enclavamiento debe aportar la documentación necesaria para demostrar que el proceso de diseño ha sido realizado de acorde a la norma CENELEC 50128. Por ello, en la fase inicial se debe crear el plan de preparación de la aplicación para plantear todos los documentos que se deben emitir. Tras cada versión de software, la propia técnica realiza pruebas internas con el fin de detectar funcionalidades llevadas a cabo incorrectamente, y una vez que se terminan dichas pruebas, se procede a la liberación oficial de la versión de software, o también denominada Release. Todas las Release que se emitan, deben ser validadas por la técnica de Data Testing, donde de forma similar a las pruebas internas, se prueba el software con el fin de identificar cualquier desviación sobre la funcionalidad deseada. Este punto corresponde a una fase posterior del ciclo de vida y será detallado en próximas actividades. Tras las pruebas realizadas por la técnica de Data Testing, es muy probable que se identifiquen funcionalidades erróneas que provoquen una revisión del software, un cambio y una posterior nueva Release. Una vez, que se genera la nueva release tras modificar el software con los cambios requeridos para corregir los fallos detectados, se debe generar un Informe de No Regresión y un Análisis de Impacto, en el cual la técnica de enclavamiento notifica los cambios producidos al software asegurando que aquello que no se declara no ha sido modificado y sigue funcionando como en la versión previa. La técnica de Data Testing debe volver a probar aquellas pruebas que apliquen al cambio realizado. Este proceso de gestión de los cambios se detallará en el capítulo 0. Todas la releases de software que se realicen deben ser recogidas en un documento de control de versiones, donde se incluye la versión del software y así como las herramientas utilizadas para su creación. También se incluyen dentro de la documentación de enclavamiento para la fase de diseño, todos aquellos documentos que están relacionados con las interfaces del enclavamiento con el resto de los productos. Documentación Hardware. La técnica de Hardware es la encargada de realizar los planos de todo el equipamiento, desde bastidores, interconexiones del sistema hasta planos de cables, y los informes de diseño hardware, en los que se mitigan aquellas SRACs que están asociadas a esta técnica. Para los cambios en los planos hardware, esta técnica también genera los Informes de No Regresión de hardware. En el caso en el que sea el tecnólogo el que diseñe la disposición de los elementos de señalización en las vías, esta técnica deberá elaborar la tira de vía. En este punto también entra el ingeniero de seguridad, ya que este diseño debe ser revisado para asegurar que se cumplen todos los requisitos de replanteo. La tira de vía debe ser de las primeras actividades en realizarse y su revisión debe ser de las primeras revisiones ya que un cambio en ella afecta potencialmente al resto del diseño. Documentación de Centros de Control. La técnica Centros de Control es la encargada de realizar el diseño y la documentación de todo el subsistema encargado de representar en los sistemas videográficos la información de la estación y permitir el control de esta de manera centralizada, mediante el CTC, o de manera local, mediante el PLO. 64. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización Ilustración 20. Estructura del Safety Case según la norma CENELEC 51029 ❖ Definición del sistema. En este apartado se describe el sistema sobre el que se va a realizar la actuación, comenzando por la misión del sistema de señalización y el perfil de la misión, es decir, los objetivos que se pretenden obtener mediante la actuación. El alcance del sistema de señalización también se incluye en este apartado y en él se suele encontrar la situación inicial del proyecto y la situación proyectada tras las actuaciones. Por último, se incluyen los componentes que van a ser suministrados por el tecnólogo y las interfaces de seguridad tanto internas (entre productos del tecnólogo dentro del alcance del proyecto) como externa (interfaz con algún producto fuera del alcance del tecnólogo). Habitualmente se incluye un apartado anterior a este, a modo de introducción, si bien éste no está definido en la norma. En él se describe el propósito del documento, el ámbito de aplicación, la estructura que se va a seguir en el safety case y la evolución de las versiones del documento. ❖ Gestión de la Calidad. En este apartado se demuestra el cumplimiento de los procedimientos de calidad establecidos y para ello se cumplimenta el informe de gestión de la calidad, donde se detalla en qué ubicación del plan de calidad se encuentran las actividades desarrolladas en el proyecto, así como los entregables elaborados que avalan las actividades. ❖ Gestión de la Seguridad. Este apartado se fundamente en el apartado 5.3 de la norma CENELEC 50129 y en él se muestran las evidencias necesarias para demostrar el cumplimiento de los procedimientos de seguridad establecidos en la norma CENELEC 50126. ❖ Informe de la Seguridad Técnica. En este apartado se deben detallar los principios técnicos que aseguran la seguridad en el diseño de la aplición y se deben incluir o referenciar aquellas evidencias que demuestran su seguimiento. La profundidad de este informe depende del nivel de integridad (SIL) de la aplicación. Su estructura, de igual forma que con el Safety Case, está definida por la norma CENELEC 50129. Ilustración 21. Estructura del Informe Técnico de Seguridad según la norma CENELEC 50129 65. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización ❖ Safety Case relacionados. En este apartado se incluyen todos aquellos Safety Case que sean de aplicación al proyecto en cuestión. Pueden ser relacionados con cualquier sistema, subsistema o equipo que sea partícipe de la aplicación específica. Se debe demostrar en todos los Safety Case incluidos que, o bien cumplen las SRACs, o bien se trasladan a la aplicación específica para ser consideradas y mitigadas. Si el Safety Case relacionado fuera de un producto genérico u otra aplicación específica, se debe incluir su versión en este apartado. ❖ Conclusiones. En este apartado se debe resumir todas las evidencias aportadas en los capítulos anteriores y se debe argumentar que el sistema, subsistema o producto para el que se realice el Safety Case es seguro y que está sujeto a las condiciones de aplicación de seguridad del proyecto. 5.4 Informe de Validación El Informe de Validación es un documento que forma parte de los entregables de la fase IX del ciclo de vida de una aplicación específica y cuyo propósito es recoger las evidencias de realización de las actividades de validación que se establecen en el Plan de Verificación y Validación. Para ello, habitualmente se incluyen una tabla donde se recogen las evidencias documentales del cumplimiento de los requisitos de seguridad, los cuales son descritos en el Hazard Log del proyecto. La estructura habitual del informe consta de 3 grandes bloques. El primer bloque comprende el propósito del documento, donde se indica cuál es el objetivo del documento, y el ámbito del mismo, donde se detalla la aplicación específica para la que ha sido realizado el informe. También se incluye en este informe un apartado de definiciones relevantes para el informe, las cuales son extraídas de la normativa de aplicación CENELEC. El segundo bloque está constituido por el detalle del proceso de validación seguido. Para ello, se definen los métodos llevados a cabo para cumplir las tareas de validación, tales como pruebas de laboratorio, pruebas de concordancia o el análisis y evaluación documental de las evidencias. El punto más importante de este bloque es la inclusión de los niveles de independencia (SIL) para los que deben realizarse las tareas de validación. Habitualmente, en los proyectos de aplicación específica de seguridad ferroviaria el nivel de independencia es SIL4. En este apartado, se indican las responsabilidades de los equipos de diseño, verificación y validación. En el tercer bloque se incluyen las tablas con todos los documentos que demuestran el cumplimiento de los requisitos de seguridad. Tras en análisis y evaluación de los documentos, se indica si éstos cumplen con los objetivos, en cuyo caso se indicaría ‘OK’, si no los cumple, en cuyo caso se indica ‘NOK’ o si está pendiente de ser evaluado o elaborado si es un documento que se genera tras la puesta en servicio. Por último, se incluye un bloque de conclusiones donde se resumen las tareas de validación realizadas y se argumenta que estas evidencias son suficientes para garantizar que todos los requisitos de seguridad están cubiertos. 5.5 Informe de Verificación El Informe de Verificación es un documento que forma parte de los entregables de la fase IX del ciclo de vida de una aplicación específica y cuyo propósito es recoger las evidencias de cumplimiento de cada una de las fases del ciclo de vida del proyecto según se establece en el Plan de Verifiación y Validación de la aplicación específica. Es un documento que se encuentra vivo durante toda la duración del proyecto. Para realizar este informe, se deben llevar a cabo las tareas de verificación para cada fase, cuyo objetivo es demostrar que se han cumplido los requisitos de cada fase. Estas tareas como se ha definido en el capítulo 3.2, según la norma CENELEC 50126, son las siguientes: ❖ Exactitud y adecuación del análisis RAMS, cuando se especifique. ❖ Conformidad de los entregables de cada fase con los entregables de las fases anteriores. 66. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización ❖ Adecuación de los métodos, herramientas y técnicas utilizados en cada fase, cuando se especifique. ❖ Exactitud, coherencia y adecuación de las especificaciones de las pruebas y de las pruebas ejecutadas, según corresponda. Es importante resaltar que los errores o deficiencias encontrados pueden requerir la reaplicación de algunas o todas las actividades de una o más fases anteriores del ciclo de vida hasta subsanarlo. Para incluir los resultados de estas tareas de verificación, se cumplimenta una ficha cuya estructura es extraída de la norma CENELEC 50126. Fase […….] (UNE-EN 50126) Referencia Descripción del documento Edición Fecha Cumplimentación de objetivos Observaciones Ilustración 22. Ficha de Verificación según norma CENELEC 50126 5.6 Hazard Log El Hazard Log (o en español, registro de peligros), según su definición en la norma CENELEC 50126, es el documento en el que los peligros identificados, las decisiones tomadas, las soluciones adoptadas y su implementación quedan registradas o referenciadas. En resumen, es la herramienta mediante la que se gestionan de forma continua los riesgos relacionados con la seguridad. Este documento se elabora en la fase III del ciclo de vida del proyecto, Análisis y valoración de riesgos, y debido a que se trata de un documento vivo a lo largo del proyecto, debe ser actualizado en las fases posteriores. Para identificar los peligros del proyecto, el Hazard Log se abastece de todos los análisis de seguridad del proyecto, recogiendo las amenazas o peligros identificados en los mismos. Como ejemplo de documento donde se identifican peligros, están el Análisis Preliminar de Riesgos o la Declaración de Riesgos Previa. El registro de peligros debe contener o hacer referencia al menos a los siguientes puntos: ❖ El propósito del registro de peligros. ❖ Cada peligro, las entidades encargadas de su gestión y las funciones o componentes que contribuyen a cada gestión. ❖ Las consecuencias probables y las frecuencias de la secuencia de incidencias asociadas a cada peligro, cuando proceda. ❖ El riesgo derivado de cada peligro (en términos cuantitativos o cualitativos), cuando proceda. ❖ Los principios de aceptación de riesgos seleccionados y, en caso de optar por la estimación explícita de riesgos, los criterios de aceptación de riesgos para demostrar la aceptabilidad del control de riesgos relacionado con los peligros. ❖ Para cada peligro, las medidas adoptadas para reducir los riesgos a un nivel aceptable o para eliminarlos. ❖ Condiciones de seguridad exportadas. En relación con este último punto, se pueden dar tres tipos de condiciones exportadas cuando la implementación del requisito de seguridad sobrepase el alcante técnico del proyecto. En primer lugar, se pueden dar las Restricciones de Servicio Temporal (RST) donde se producen situaciones de peligro de carácter temporal. Habitualmente, el administrador ferroviario debe implementar procedimientos operacionales para que la explotación del sistema durante la existencia del peligro sea segura. Un ejemplo de Restricción de Servicio Temporal, es la embridación de una aguja para evitar la circulación de 67. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización material rodante en una vía dada de baja por causas de mantenimiento. Las RST suelen implicar limitaciones al servicio. En segundo lugar, se pueden dar las Condiciones de Aplicación (CA), las cuales son las hipótesis de partida del proyecto y que condicionan la explotación del sistema. Un ejemplo de CA es cuando el programa de explotación o PEX, es una entrada para el tecnólogo y debe adaptar el sistema de señalización a él. La tira de vía con la ubicación de los elementos también puede ser una entrada que genere una CA. Por último, se pueden dar las Condiciones de Uso (CU). Éstas son las consideraciones a tener en cuenta en la explotación del sistema. A diferencia de las RST, éstas son perennes al ciclo de vida del sistema. Se pueden dividir en CU de sistema, si son limitaciones propias de los equipos, o CU de operación, si deben ser tenidas por la propia explotación. Por ejemplo, existen condiciones de uso en la instalación y puesta en servicio. 5.7 Safety SRACs Las condiciones de aplicación relacionadas con la seguridad o SRACs, por sus siglas en inglés Safety Related Application Conditions, son aquellos requisitos específicos (condiciones de aplicación) que deben cumplirse durante el uso de un producto o sistema para garantizar la seguridad (safety related) en su aplicación. Éstas pueden contener limitaciones de uso, requisitos de mantenimiento o condiciones operativas específicas que mitigarán los riesgos cuando el sistema o subsistema considerado está integrado en un sistema global. La correcta gestión de las SRACs es una precondición necesaria para una integración segura de un producto en un sistema. A modo de compilación de todas las SRACs, en el proyecto se genera el documento “Listado de productos y SRACs”, en el cual se recogen todos los productos que se van a utilizar en la aplicación específica, sus versiones de producto genérico y las SRACs asociadas a esos productos o a su integración. Este documento es realizado por el líder técnico del proyecto o TPL (en inglés, Technical Project Leader) si dicha figura existe en el projecto, por la técnica de Sistemas, si está involucrada en el proyecto, o en último lugar por el Project Manager (PM). El autor del documento es el encargado de asignar la responsabilidad de cada productor al Delivery Manager (DM) de la técnica correspondiente, el cual es el encargado de filtrar e incluir las SRACs que apliquen al proyecto y asignarlas al responsable de incluir las evidencias de mitigación. En este punto es donde entra la técnica de Project Assurance (PA), ya que dentro de sus responsabilidades del projecto, además de realizar el dossier de seguridad, debe mitigar sus propias SRACs en el documento de Safety SRACs. 68. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización 6 OTROS CONCEPTOS Y ACTIVIDADES Para realizar la gestión de la seguridad en los proyectos ferroviarios, es importante que el ingeniero de seguridad se desenvuelva con soltura manejando varios concepto y actividades. Este es el caso de los tres próximos capítulos, donde en el capítulo 6.1 se describe cómo se deben gestionar una modificación del software o del hardware tanto en la fase de diseño como cuando el sistema ya se encuentra en la fase de operación. En el capítulo 6.2, se describen la metodología según la normativa CENELEC para evaluar los riesgos del sistema, el cual es el aspecto más importante de la gestión de la seguridad. Por último, en el capítulo 6.3 se describe la relación que el ingeniero de seguridad debe mantener con el evaluador independiente, ya que para la operación segura del sistema es imprescindible contar con una evaluación independiente de la seguridad. 6.1 Gestión de los cambios En la actividad de Gestión de la documentación de diseño, se han dado pinceladas acerca de la gestión del cambio en las versiones de software del enclavamiento y del sistema videográfico. En esta sección, se profundizará en todo el proceso necesario para llevar a cabo el cambio en un software. Para poder llevar a cabo un proceso de cambio debemos poseer previamente una versión de datos ya validada, sobre la cual se realizará una petición de cambio. Esta petición de cambio será el documento qe justifique el cambio a realizar y se puede dar por la implementación de una nueva funcionalidad o por un informe tipo FRACAS. En el caso en el que el cambio se produzca por un error encontrado en las pruebas de validación, se generará un Test Log. Tras obtener la petición de cambio, se inicia el proceso de modificación donde la técnica que ha recibido la petición de cambio sobre su software la analiza y diseña la modificación a implementar para corregir el error o implementar la nueva funcionalidad. El diseñador debe recoger la versión del software previa al cambio y proveer el alcance y una breve descripción del cambio. El diseñador de la técnica correspondiente debe poseer las herramientas de comprobación necesarias para realizar el checkeo de que en la nueva versión sólo ha cambiado la funcionalidad deseada y que no se ha modificado ninguna funcionalidad no deseada. Todo lo anterior se recoger en el documento denominado Informe de No Regresión donde se deben reflejar las versiones inicial y final del software, el alcance y descripción de los cambios implementados, identificación de los elementos afectados por el cambio y las evidencias de que el resto del softwre no ha sido alterado. Esta fase del INR se considera la fase de generación. Una vez generado el INR, el validador o responsable de la técnica de Data Testing, debe analizar el cambio implementado en el software y determinar las pruebas que se deben volver a pasar para asegurar que el software sigue cumpliendo con todos los requisitos y que la funcionalidad es la esperada. Por último, el validador incluirá en el INR las pruebas que han sido pasadas, así como sus resultados, y la versión de software que ha sido validada, la cual debe coincidir con la versión final del software indicada por el diseñador. El trabajo del ingeniero de seguridad en este proceso es verificar que la trazabilidad de la petición del cambio y el alcance de la modificación es correcta y la revisión de que las pruebas pasadas por el validador son las necesarias para asegurar la funcionalidad del software. Además, se debe comprobar que las versiones indicadas como final por el diseñador y el validador son las mismas. 69. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización 6.2 Evaluación de riesgos En esta sección se va a profundizar en el análisis y la evaluación de riesgos, la cual se lleva a cabo principalmente en la fase III del ciclo de vida, aunque puede ser continuada más adelante. El proceso de análisis de riesgos es un proceso iterativo donde se identifican todos los factores que contribuyen al riesgo. Comenzando por la definición del sistema, se deben identificar todos los peligros, riesgos, medidas de seguridad y requisitos de seguridad resultantes. En este análisis también se incluyen el análisis de las consecuencias, ya sea de forma cuantitativa o cualitativa. En el caso en el que se considere necesario apoyar la identificación de peligros, su clasificación o los principios de aceptación del riesgo, se debe definir un modelo de riesgos. Este modelo relaciona las casusas, peligros y accidentes e incluye entre sus variables las condiciones del entorno y el contexto operativo. El objetivo del modelo es obtener la forma en la que un peligro a nivel sistema o a nivel ferroviario, bajo ciertas circunstancias, puede desencadenar en un accidente. Para más información se debe revisar la norma 50126-2. Para realizar el análisis de las consecuencias se pueden utilizar diferentes técnicas en apoyo del juicio de expertos. Alguna de estas técnicas son el Análisis de modos de fallo, sus efectos y su criticidad (FMECA), un Diagrama causa-efecto, un análisis por árbol de eventos o de fallos. El juicio de expertos también es utilizado para la evaluación de riesgos en aquellos casos en los que el enfoque cuantitativo no sea posible, aunque no es exclusivo del enfoque cualtitativo. Una vez que se han analizado los riesgos y evaluado las posibles consecuencias, se deben establecer los principios de aceptación de los riesgos, que se resumen en tres: código de buenas prácticas, uso de sistema de referencia y estimación explícita del riesgo. El código de buenas prácticas se puede utilizar como principio de aceptación de riesgos siempre que se trate de un conjunto de normas ampliamente reconocido en el ámbito ferroviarios y que sea pertinente para el control de peligros del sistema en consideración. Si los peligros son controlados mediante este principio, los riesgos serán considerados aceptables. El uso de un sistema de referencia se puede utilizar como principio de aceptación de riesgos siempre que se haya demostrado que tiene un nivel de seguridad aceptable, que tiene funciones e interfaces similares y que ha sido utilizado en condiciones operativas y de entorno similares durante un periodo de tiempo suficiente y ha dado la confianza necesaria. Si los peligros son controlados mediante este principio, los riesgos serán considerados aceptables. La estimación explícita de riesgos se utiliza como principio de aceptación de riesgos cuando los peligros no están cubiertos, total o parcialmente, por alguno de los principios anteriores. Este principio puede ser realizado tanto cuantitativa como cualitativamente. Al aplicarlo se deben definir los criterios de aceptación del riesgo y demostrar que las medidas de seguridad aplicadas son capaces de reducir el riesgo para cumplir el criterio definido. 6.3 Evaluación Independiente En este capítulo se va a profundizar en la tarea de la evaluación independiente de la seguridad, la cual se lleva a cabo en la fase IX del ciclo de vida del proyecto. Según la norma CENELEC 50129, la evaluación independiente de la seguridad es “la formación de un juicio autónomo e independiente respecto a cualquier persona perteneciente al equipo de diseño, desarrollo, explotación y mantenimiento del sistema”. Su objetivo es asegurar que se cumplen los requisitos, que el proceso de seguridad se haya implementado correctamente y que el sistema, desde el punto de vista de la seguridad, es adecuado para el uso previsto. Para ello, debe ser aceptado por el responsable del servicio ferroviario de conformidad con el marco legal. Si durante la evaluación se detectase un problema de seguridad fuera de las competencias del evaluador, este debe ser notificado lo antes posibles a la persona que corresponda. En el caso en el que se evalúe un sistema con integridad básica, sólo se debe evaluar la conformidad y corrección del proceso hasta la asignación SIL, es decir, fases IV y V del ciclo de vida. 70. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización Para lograr estos objetivos, el evaluador debe tener libertad para seleccionar las herramientas que considere necesarias, como entrevistas, análisis, auditorías, presenciar ensayos y/o realizar inspecciones físicas. El resultado de la evaluación se debe presentar en un informe que desarrolle las actividades realizadas por el evaluador. En el informe se podrán incluir condiciones adicionales para el funcionamiento del sistema. 71. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización 7 ANEXO I: LISTADO DE DOCUMENTACIÓN A lo largo de este proyecto se han definido los procesos necesarios para llevar a cabo un estudio de seguridad para el subsistema de Control, Mando y Señalización en una aplicación específica ferroviaria. Se ha comenzado por una introducción a los sistemas ferroviarios, pasando por la normativa que rige los estudios de seguridad, la metodología empleada para cumplir todos los puntos de la normativa y concluyendo con la revisión de los principales documentos de seguridad. En este anexo se incluye un listado genérico de documentación para un proyecto, es decir, para cualquier proyecto ferroviario que incluya una actuación sobre el subsistema CMS se debe generar la documentación que a continuación se incluye. Fase I y II. Concepto y definición del sistema y contexto operativo. Título del documento Técnica Responsable Definición del sistema del proyecto Project Manager Plan de Pruebas y Puesta en Servicio Test & Commissioning Plan de Calidad Calidad Plan de Seguridad Project Assurance Plan de Verificación y Validación Project Assurance Programa de Explotación Administrador Ferroviario / Enclavamiento (01) Tira de vía Administrador Ferroviario / Enclavamiento (01) Plan de preparación de la aplicación Enclavamiento Observaciones: (01) El Programa de Explotación es un documento que puede ser una entrada para el tecnólogo y por tanto el autor será el Administrador Ferroviario o, por otro lado, puede ser elaborado por el tecnólogo, en cuyo caso lo elaboraría la técnica de Enclavamiento. Fase III. Análisis y valoración de riesgos. Título del documento Técnica Responsable Declaración de Riesgos Previa Project Assurance Hazard Log Project Assurance Análisis de seguridad de gestión de comandos especiales Project Assurance Listado de productos, versiones y SRAC para el proyecto TPL / Sistemas (02) 72. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización Safety Engineering Checklist (Safety SRACs) Project Assurance Informe de justificación de SRACs (03) Técnica responsable del producto Observaciones: (02) Depende de la figura existente en el proyecto. (03) Existen tantos documentos de justificación de SRACs como productos se incluyan en el proyecto. El responsable del documento será el responsable de dicho producto. Pueden existir varios informes para un mismo producto, uno para cada técnica que deba justificar SRACs. Fase IV. Especificación de los requisitos del sistema. Título del documento Técnica Responsable Requisitos funcionales del enclavamiento para el administrador ferroviario Enclavamiento Norma de Sistemas Videográficos Centros de Control Criterios de Replanteo de equipos de señalización en Vía Hardware Documento de recopilación de requisitos para un subsistema o producto. Técnica responsable del subsistema o producto Fase V. Arquitectura y asignación de los requisitos del sistema. Título del documento Técnica Responsable Protocolo de pruebas de Enclavamiento y/o PLO Data Testing Procedimiento de pruebas de concordancia Test & Commissioning Manual de integración de la interfaz entre un producto y el enclavamiento Ejemplos de productos: Señales, Contadores de Ejes, Circuitos de vía, Pasos a Nivel Técnica responsable del producto Documento de recopilación de requisitos para un subsistema o producto. Técnica responsable del subsistema o producto 73. Nociones básicas de la normativa CENELEC en la aplicación específica de los proyectos ferroviarios de señalización Fase VI. Diseño e Implementación. Título del documento Técnica Responsable Documentación Hardware Planos Hardware Se suele incluir: ❖ Planos de cables ❖ Planos de bastidores del Enclavamiento ❖ Planos de bastidores de Circuitos de Vía ❖ Planos de cajas ❖ Planos de interconexionado del sistema Hardware Informes de Diseño Hardware Hardware Informe de No Regresión Hardware Hardware Documentación Enclavamiento Estudio de proximidades Enclavamiento Control de versiones de Enclavamiento Enclavamiento Informe de No Regresión de Enclavamiento Enclavamiento Análisis de Impacto para datos de Enclavamiento Enclavamiento Descripción de anillos libres utilizados para el Enclavamiento Enclavamiento Mapa de interfaz Enclavamiento-Producto Puede haber para contadores de ejes, pasos a nivel, etc. Enclavamiento Documentación de Centros de Control Baseline de documentación Centros de Control Control de versiones Un documento para: PLO, CTC, PCI, CCIA Centros de Control Informe de No Regresión Un documento para: PLO, CTC, PCI, CCIA Centros de Control Informe de configuración de datos y configuración de PLO Centros de Control Release Note Centros de Control Manual de Mantenimiento de aplicación específica Centros de Control