Norma Española
UNE-EN 50126-2
Septiembre 2018
Aplicaciones ferroviarias
Especificación y demostración de la fiabilidad, la
disponibilidad, la mantenibilidad y la seguridad
(RAMS)
Parte 2: Aproximación sistemática para la seguridad
Esta norma ha sido elaborada por el comité técnico
CTN 203 Equipamiento eléctrico y sistemas automáticos
para la industria, cuya secretaría desempeña SERCOBE.
Asociación Española
de Normalización
Génova, 6 - 28004 Madrid
915 294 900
info@une.org
www.une.org
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2
Aplicaciones ferroviarias
Especificación y demostración de la fiabilidad, la disponibilidad, la mantenibilidad
y la seguridad (RAMS)
Parte 2: Aproximación sistemática para la seguridad
Railway Applications. The Specification and Demonstration of Reliability, Availability, Maintainability
and Safety (RAMS). Part 2: Systems Approach to Safety.
Applications ferroviaires. Spécification et démonstration de la fiabilité, de la disponibilité, de la
maintenabilité et de la sécurité (FDMS). Partie 2: Approche systématique pour la sécurité.
Esta norma es la versión oficial, en español, de la Norma Europea EN 50126-2:2017.
Las observaciones a este documento han de dirigirse a:
Asociación Española de Normalización
Génova, 6
28004 MADRID-España
Tel.: 915 294 900
info@une.org
www.une.org
Depósito legal: M 29927:2018
 UNE 2018
Publicado por AENOR INTERNACIONAL S.A.U. bajo licencia de la Asociación Española de Normalización.
Reproducción prohibida
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
EN 50126-2
NORMA EUROPEA
EUROPEAN STANDARD
NORME EUROPÉENNE
EUROPÄISCHE NORM
Octubre 2017
ICS 45.020
Sustituye a CLC/TR 50126-2:2007
Versión en español
Aplicaciones ferroviarias
Especificación y demostración de la fiabilidad, la disponibilidad,
la mantenibilidad y la seguridad (RAMS)
Parte 2: Aproximación sistemática para la seguridad
Railway Applications. The Specification
and Demonstration of Reliability,
Availability, Maintainability and Safety
(RAMS). Part 2: Systems Approach to
Safety.
Applications ferroviaires. Spécification
et démonstration de la fiabilité, de la
disponibilité, de la maintenabilité et de
la sécurité (FDMS). Partie 2: Approche
systématique pour la sécurité.
Bahnanwendungen. Spezifikation und
Nachweis von Zuverlässigkeit,
Verfügbarkeit, Instandhaltbarkeit und
Sicherheit (RAMS). Teil 2:
Systembezogene Sicherheitsmethodik.
Esta norma europea ha sido aprobada por CENELEC el 2017-07-03. Los miembros de CENELEC están
sometidos al Reglamento Interior de CEN/CENELEC que define las condiciones dentro de las cuales
debe adoptarse, sin modificación, la norma europea como norma nacional.
Las correspondientes listas actualizadas y las referencias bibliográficas relativas a estas normas
nacionales, pueden obtenerse en el Centro de Gestión de CEN/CENELEC, o a través de sus miembros.
Esta norma europea existe en tres versiones oficiales (alemán, francés e inglés). Una versión en otra
lengua realizada bajo la responsabilidad de un miembro de CENELEC en su idioma nacional, y
notificada al Centro de Gestión de CEN/CENELEC, tiene el mismo rango que aquéllas.
Los miembros de CENELEC son los comités electrotécnicos nacionales de normalización de los países
siguientes: Alemania, Antigua República Yugoslava de Macedonia, Austria, Bélgica, Bulgaria, Chipre,
Croacia, Dinamarca, Eslovaquia, Eslovenia, España, Estonia, Finlandia, Francia, Grecia, Hungría,
Irlanda, Islandia, Italia, Letonia, Lituania, Luxemburgo, Malta, Noruega, Países Bajos, Polonia, Portugal,
Reino Unido, República Checa, Rumanía, Serbia, Suecia, Suiza y Turquía.
COMITÉ EUROPEO DE NORMALIZACIÓN ELECTROTÉCNICA
European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
CENTRO DE GESTIÓN: Rue de la Science, 23, B-1040 Brussels, Belgium
 2017 CENELEC. Derechos de reproducción reservados a los Miembros de CENELEC.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
-4-
Índice
Prólogo europeo .................................................................................................................................7
0
Introducción ........................................................................................................................8
1
Objeto y campo de aplicación........................................................................................9
2
Normas para consulta ................................................................................................... 10
3
Términos y definiciones............................................................................................... 11
4
Abreviaturas..................................................................................................................... 11
5
5.1
5.2
5.2.1
5.2.2
5.3
5.4
5.5
5.6
Proceso de seguridad .................................................................................................... 12
Evaluación de riesgos y control de peligros ......................................................... 12
A. Evaluación de riesgos ............................................................................................... 14
Generalidades .................................................................................................................. 14
Realización de la evaluación de riesgos ................................................................. 14
B. Resultado de la evaluación de riesgos ............................................................... 14
C. Control de peligros .................................................................................................... 15
D. Revisión de la evaluación de riesgos .................................................................. 16
Responsabilidades ......................................................................................................... 17
6
6.1
6.2
6.3
6.4
6.5
6.6
Demostración y aceptación de la seguridad ......................................................... 17
Introducción ..................................................................................................................... 17
Demostración de la seguridad y proceso de aceptación de la
seguridad ........................................................................................................................... 17
Responsabilidad en la gestión del caso de seguridad ....................................... 21
Modificaciones tras la aceptación de seguridad ................................................. 21
Dependencias entre casos de seguridad ................................................................ 22
Relación entre los casos de seguridad y la arquitectura del sistema .......... 23
7
7.1
7.2
7.3
7.4
Organización e independencia de las funciones ................................................. 24
Generalidades .................................................................................................................. 24
Fases iniciales del ciclo de vida (fases 1 a 4) ........................................................ 25
Fases posteriores del ciclo de vida (a partir de la fase 5) ................................ 26
Competencia del personal ........................................................................................... 27
8
8.1
8.2
8.2.1
8.2.2
8.2.3
8.2.4
8.3
8.3.1
8.3.2
8.3.3
8.4
8.4.1
Evaluación de riesgos.................................................................................................... 28
Introducción ..................................................................................................................... 28
Análisis de riesgos.......................................................................................................... 28
Generalidades .................................................................................................................. 28
El modelo de riesgos...................................................................................................... 29
Técnicas para el análisis de consecuencias .......................................................... 31
Juicio de expertos ........................................................................................................... 32
Principios de aceptación de riesgos y valoración de riesgos ......................... 33
Uso del código de buenas prácticas ......................................................................... 33
Uso de un sistema de referencia ............................................................................... 33
Uso de una estimación explícita de riesgos .......................................................... 34
Aplicación de la estimación explícita de riesgos ................................................. 35
Enfoque cuantitativo ..................................................................................................... 35
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
-5-
UNE-EN 50126-2:2018
8.4.2
8.4.3
Variabilidad utilizando estimaciones de riesgo cuantitativas ....................... 39
Enfoques cualitativos y semicuantitativos ............................................................ 41
9
9.1
9.2
9.3
9.3.1
9.3.2
9.3.3
9.3.4
Especificación de los requisitos de seguridad del sistema.............................. 41
Generalidades .................................................................................................................. 41
Requisitos de seguridad ............................................................................................... 41
Categorización de los requisitos de seguridad .................................................... 42
Generalidades .................................................................................................................. 42
Requisitos de seguridad funcional ........................................................................... 43
Requisitos de seguridad técnica ............................................................................... 44
Requisitos de seguridad contextual ........................................................................ 44
10
Distribución de los requisitos de integridad de la seguridad
funcional ............................................................................................................................ 45
10.1
Obtención y distribución de los requisitos de seguridad del sistema......... 45
10.2
Integridad de la seguridad funcional de los sistemas electrónicos ............. 45
10.2.1 Obtención de requisitos de seguridad funcional para sistemas
electrónicos ...................................................................................................................... 45
10.2.2 Distribución de los requisitos de seguridad ......................................................... 45
10.2.3 Factores de integridad de la seguridad .................................................................. 48
10.2.4 Integridad de la seguridad funcional y fallos aleatorios .................................. 49
10.2.5 Aspecto sistemático de la integridad de la seguridad funcional ................... 49
10.2.6 Requisitos equilibrados para el control de fallos aleatorios y
sistemáticos ...................................................................................................................... 49
10.2.7 Tabla de niveles de integridad de la seguridad (SIL) ........................................ 51
10.2.8 Asignación de nivel de integridad de la seguridad (SIL) .................................. 51
10.2.9 Distribución de la TFFR (tasa de fallo funcional tolerable) después
de la asignación del SIL (nivel de integridad de la seguridad) ...................... 52
10.2.10 Demostración de objetivos cuantificados.............................................................. 52
10.2.11 Requisitos para la integridad básica ....................................................................... 52
10.2.12 Prevención del uso incorrecto de los SIL (niveles de integridad de la
seguridad) ......................................................................................................................... 54
10.3
Integridad de la seguridad para sistemas no electrónicos. Aplicación
del Código de buenas prácticas ................................................................................. 54
11
11.1
11.2
11.3
11.4
Diseño e implementación ............................................................................................ 56
Introducción ..................................................................................................................... 56
Análisis causal ................................................................................................................. 56
Identificación de peligros (refinamiento) ............................................................. 57
Análisis de causas comunes ........................................................................................ 58
Anexo A (Informativo) ALARP, GAME, MEM ...................................................................... 59
A.1
ALARP, GAME, MEM como métodos para definir los criterios de
aceptación de riesgos .................................................................................................... 59
A.2
ALARP (Tan bajo como sea razonablemente práctico) .................................... 61
A.2.1
Generalidades .................................................................................................................. 61
A.2.2
Tolerancia y ALARP ....................................................................................................... 61
A.3
Principio GAME (Globalmente al menos equivalente)...................................... 62
A.3.1
Principio ............................................................................................................................ 62
A.3.2
Aplicación del principio GAME .................................................................................. 63
A.3.2.1 Generalidades .................................................................................................................. 63
A.3.2.2 Principios básicos........................................................................................................... 63
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
-6-
A.3.2.3 Aplicación del principio GAME para construir un argumento
cualitativo de seguridad............................................................................................... 63
A.3.2.4 Aplicación del principio GAME utilizando objetivos cuantitativos de
riesgo .................................................................................................................................. 64
A.4
Mortalidad Mínima Endógena, MEM........................................................................ 64
Anexo B (Informativo)
Utilización de estadísticas de fallos y accidentes
para obtener una tasa de peligro tolerable (THR) ........... 66
Anexo C (Informativo)
Directrices para la asignación de un nivel de
integridad de la seguridad (SIL) .............................................. 68
Anexo D (Informativo)
D.1
D.2
D.2.1
D.2.2
D.3
D.3.1
D.3.2
D.3.3
D.3.4
D.3.5
Métodos de distribución de los objetivos de
seguridad ......................................................................................... 70
Análisis del sistema y de los métodos ..................................................................... 70
Ejemplo de método cualitativo de distribución .................................................. 70
Generalidades .................................................................................................................. 70
Ejemplo de método cualitativo para la eficacia de las medidas de
protección ......................................................................................................................... 71
Ejemplo de método cuantitativo de distribución ............................................... 73
Introducción ..................................................................................................................... 73
Funciones con mecanismos independientes de detección y anulación
de fallos .............................................................................................................................. 75
Función y medida de protección independiente que actúa como
mecanismo de detección y anulación de fallos .................................................... 77
Distribución de un objetivo de probabilidad de seguridad ............................ 78
Distribución de un objetivo de seguridad "por hora" ....................................... 79
Anexo E (Informativo) Errores comunes en la cuantificación ................................... 80
E.1
Usos erróneos comunes ............................................................................................... 80
E.2
Mezcla de tasas de fallo con probabilidades ........................................................ 80
E.3
Utilización de fórmulas fuera de su ámbito de aplicación............................... 81
Anexo F (Informativo)
Técnicas/métodos para el análisis de seguridad .............. 82
Anexo G (Informativo)
Funciones y responsabilidades clave en materia de
seguridad del sistema ................................................................. 85
Anexo ZZ (Informativo) Relación entre esta norma europea y los requisitos
esenciales de la Directiva 2008/57/CE................................. 90
Bibliografía ........................................................................................................................................ 94
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
-7-
UNE-EN 50126-2:2018
Prólogo europeo
Esta Norma EN 50126-2:2017 fue preparada por el Comité Técnico TC 9X, Equipos y sistemas eléctricos
para ferrocarriles, de CENELEC.
Se fijaron las siguientes fechas:
– Fecha límite en la que la norma debe adoptarse a nivel nacional
por publicación de una norma nacional idéntica o por
ratificación
(dop)
2018-07-03
– Fecha límite en la que deben retirarse las normas nacionales
divergentes con esta norma
(dow)
2020-07-03
Esta norma sustituye al Informe Técnico CLC/TR 50126-2:2007.
La edición anterior del Informe Técnico CLC/TR 50126-2:2007 ha quedado obsoleta con las nuevas
ediciones de las Normas EN 50126-1:2017 y EN 50126-2:2017; la razón es que el campo de aplicación
de esta parte se ha modificado con respecto a la versión anterior a la que sustituye.
Se llama la atención sobre la posibilidad de que algunos de los elementos de este documento estén
sujetos a derechos de patente. CENELEC no es responsable de la identificación de dichos derechos de
patente.
La Norma EN 50126 "Aplicaciones ferroviarias. Especificación y demostración de la fiabilidad, la
disponibilidad, la mantenibilidad y la seguridad (RAMS)" consta de las siguientes partes:
– Parte 1: Procesos RAMS genéricos.
– Parte 2: Aproximación sistemática para la seguridad.
Esta norma europea ha sido preparada bajo un mandato dado a CENELEC por la Comisión Europea y
por la Asociación Europea de Libre Comercio y sirve de apoyo a los requisitos esenciales de la(s)
Directiva(s) CE.
La relación con las Directivas UE se recoge en el anexo informativo ZZ, que forma parte integrante de
esta norma.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
-8-
0 Introducción
El objetivo de la Norma EN 50126-1:1999 era introducir la aplicación de un proceso de gestión
sistemática de RAMS en el sector ferroviario. Aplicando esta norma y las experiencias adquiridas en
los últimos años, la necesidad de revisión y reestructuración se puso de manifiesto para contar con un
enfoque sistemático y coherente de RAMS aplicable a todos los campos de aplicación ferroviarios:
Mando, Control y Señalización, Material Rodante e Instalaciones Fijas.
El trabajo de revisión mejoró la coherencia y congruencia de la norma, el concepto de gestión de la
seguridad y el uso práctico de la Norma EN 50126, y tuvo en cuenta los Informes Técnicos existentes y
relacionados.
Esta norma europea proporciona a los responsables del servicio ferroviario y a los proveedores
ferroviarios de toda la Unión Europea, un proceso que permitirá la implementación de un enfoque
coherente para la gestión de la fiabilidad, disponibilidad, mantenibilidad y seguridad, denominado
RAMS.
Los procesos para la especificación y demostración de los requisitos de RAMS son la base de esta
norma. Esta norma europea promueve una comprensión y un enfoque comunes de la gestión de RAMS.
La Norma EN 50126 forma parte de la aplicación específica para el sector ferroviario de la Norma
IEC 61508. El cumplimiento de los requisitos de esta norma europea, junto con los requisitos de otras
normas apropiadas, es suficiente para garantizar que no es necesario demostrar el cumplimiento
adicional de la Norma IEC 61508.
Por lo que se refiere a la seguridad, la Norma EN 50126-1 proporciona un Proceso de Gestión de la
Seguridad que se apoya en directrices generales y métodos descritos en la Norma EN 50126-2.
Las Normas EN 50126-1 y EN 50126-2 son independientes de la tecnología utilizada. En lo que
respecta a la seguridad, la Norma EN 50126 adopta la perspectiva de la seguridad con un enfoque
funcional.
La aplicación de esta norma puede adaptarse a los requisitos específicos del sistema en consideración.
Los responsables del servicio ferroviario y los proveedores ferroviarios pueden aplicar
sistemáticamente esta norma europea a lo largo de todas las fases del ciclo de vida de una aplicación
ferroviaria para desarrollar requisitos de RAMS específicos para el ferrocarril y lograr el cumplimiento
de estos requisitos. El enfoque a nivel de sistema desarrollado por esta norma europea facilita la
evaluación de las interacciones de RAMS entre elementos de aplicaciones ferroviarias, aunque sean de
naturaleza compleja.
Esta norma europea promueve la cooperación entre las partes interesadas de los ferrocarriles para la
consecución de una combinación óptima de RAMS y costes para aplicaciones ferroviarias. La adopción
de esta norma europea apoyará los principios del Mercado Único Europeo y facilitará la
interoperabilidad ferroviaria en Europa.
De conformidad con las reglas de edición de CENELEC1), en esta norma los requisitos obligatorios se
indican con el verbo "debe" ("shall" en inglés). Cuando se considere justificado, la norma permite la
adaptación del proceso.
1) Parte 3 del Reglamento Interno de CEN/CENELEC: Reglas para la estructura y redacción de las publicaciones
CEN/CENELEC (2017-02), anexo H.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
-9-
UNE-EN 50126-2:2018
En la Norma EN 50126-2 se proporcionan directrices generales específicas sobre la aplicación de esta
norma para aspectos de seguridad. La Norma EN 50126-2 proporciona varios métodos para su uso en
el proceso de gestión de la seguridad. Cuando se elija un método particular para el sistema en
consideración, los requisitos obligatorios para dicho método tienen consecuentemente carácter
obligatorio para la gestión de la seguridad del sistema en consideración.
Esta norma europea consta de una parte principal (capítulo 1 a capítulo 8) y de los anexos A, B, C, D, E,
F, G y ZZ. Los requisitos definidos en la parte principal de la norma son normativos, mientras que los
anexos son informativos.
1 Objeto y campo de aplicación
Esta parte 2 de la Norma EN 50126
• considera los aspectos genéricos relacionados con la seguridad del ciclo de vida de RAMS;
• define métodos y herramientas independientes de la tecnología actual de sistemas y subsistemas;
• proporciona:
– al usuario de la norma el entendimiento sobre la aproximación sistemática para la seguridad,
que es un concepto clave de la serie de Normas EN 50126,
– métodos para determinar los requisitos de seguridad y los requisitos de integridad de seguridad
del sistema así como métodos para asignarlos a los subsistemas,
– métodos para determinar los niveles de integridad de la seguridad (SIL) para las funciones
electrónicas relacionadas con la seguridad;
NOTA Esta norma no permite la asignación de niveles de integridad de la seguridad a funciones no electrónicas.
• proporciona directrices generales y métodos para las siguientes áreas:
– proceso de seguridad,
– demostración y aceptación de la seguridad,
– organización e independencia de funciones,
– evaluación de riesgos,
– especificación de los requisitos de seguridad,
– asignación de los requisitos de seguridad funcional,
– diseño e implementación;
• proporciona al usuario de esta norma los métodos para garantizar la seguridad con respecto al
sistema en consideración y sus interacciones;
• proporciona directrices generales sobre la definición del sistema en consideración, incluida la
identificación de las interfaces y las interacciones de este sistema con sus subsistemas u otros
sistemas, a fin de llevar a cabo el análisis de riesgos;
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 10 -
• no define:
– objetivos, cantidades, requisitos o soluciones RAMS para aplicaciones ferroviarias específicas,
– las normas o procesos relativos a la certificación de los productos ferroviarios en relación con
los requisitos de esta norma,
– un proceso de aprobación por parte de la autoridad de seguridad.
Esta parte 2 de la Norma EN 50126 es aplicable a aplicaciones ferroviarias, a saber, Mando, Control y
Señalización, Material Rodante e Instalaciones Fijas, y específicamente:
• a la especificación y demostración de seguridad para todas las aplicaciones ferroviarias y a todos
los niveles de dichas aplicaciones, desde sistemas ferroviarios completos hasta sistemas principales
e individuales y los subsistemas y componentes combinados dentro de estos sistemas principales,
incluidos los que contengan software:
– a los nuevos sistemas,
– a los nuevos sistemas integrados en los sistemas existentes ya aceptados, siempre que se esté
integrando el nuevo sistema con la nueva funcionalidad. De no ser así, no es aplicable a ningún
aspecto no modificado del sistema existente,
– en la medida de lo razonablemente posible, a las modificaciones y ampliaciones de los sistemas
existentes ya aceptados antes de la creación de esta norma, siempre que se modifiquen los
sistemas existentes. De no ser así, no es aplicable a ningún aspecto no modificado del sistema
existente;
• en todas las fases relevantes del ciclo de vida de una aplicación;
• para su uso por parte de los responsables del servicio ferroviario y de los proveedores ferroviarios.
No es obligatorio aplicar esta norma a los sistemas existentes que no hayan sido modificados, incluidos
los sistemas ya compatibles con cualquier versión anterior de la Norma EN 50126.
El proceso definido por esta norma europea supone que los responsables del servicio ferroviario y los
proveedores ferroviarios cuentan con políticas a nivel empresarial que abordan Calidad, Rendimiento
y Seguridad. El enfoque definido en esta norma es coherente con la aplicación de los requisitos de
gestión de calidad contenidos en la Norma EN ISO 9001.
2 Normas para consulta
En el texto se hace referencia a los siguientes documentos de manera que parte o la totalidad de su
contenido constituyen requisitos de este documento. Para las referencias con fecha, solo se aplica la
edición citada. Para las referencias sin fecha se aplica la última edición (incluida cualquier
modificación de esta).
EN 50126-1:2017, Aplicaciones ferroviarias. Especificación y demostración de la fiabilidad, la
disponibilidad, la mantenibilidad y la seguridad (RAMS). Parte 1: Procesos RAMS genéricos.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 11 -
UNE-EN 50126-2:2018
3 Términos y definiciones
Para los fines de este documento, se aplican los términos y definiciones incluidos en la Norma
EN 50126-1.
4 Abreviaturas
ALARP
Tan bajo como sea razonablemente práctico (As Low As Reasonably Practicable)
CBA
Análisis Costes-Beneficios (Cost Benefit Analysis)
CCF
(Análisis de) Fallos de Causa Común (Common Cause Failure (Analysis))
CoP
Código de buenas prácticas (Code of Practice)
COTS
Comercial (Commercial off-the-shelf)
DRA
Aversión Diferencial al Riesgo (Differential Risk Aversion)
ERE
Estimación explícita del riesgo (Explicit Risk Estimation)
CEM
Compatibilidad electromagnética
ETA
Análisis por Árbol de Eventos (Event Tree Analysis)
FMECA
Análisis de modos de fallo, de sus efectos y de su criticidad (Failure Mode Effect &
Criticality Analysis)
AAF
Análisis por árbol de fallos
GA
Aplicación Genérica (Generic Application)
GASC
Caso de Seguridad para Aplicaciones Genéricas (Generic Application Safety Case)
GP
Producto Genérico (Generic Product)
GPSC
Caso de Seguridad para Productos Genéricos (Generic Product Safety Case)
GAME
Globalmente al menos equivalente (Globalement Au Moins Equivalent)
HAZOP
Estudio de peligros y operatividad (Hazard and Operability study)
IM
Administrador de Infraestructura (Infrastructure Manager)
LRU
Unidad Sustituible en Línea (Line replaceable Unit)
MEM
Mínima Mortalidad Endógena (Minimum Endogenous Mortality)
RAC
Criterio de aceptación de riesgos (Risk Acceptance Criteria)
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 12 -
RAMS
Fiabilidad, Disponibilidad,
Maintainability and Safety)
Mantenibilidad
Seguridad
(Reliability,
Availability,
RAP
Principio de Aceptación de Riesgos (Risk Acceptance Principle)
RBD
Diagrama de bloques de la fiabilidad (Reliability Block Diagram)
RRA
Análisis Rápido de Ranking (Rapid Ranking Analysis)
RU
Operador de Material Rodante (Railway Undertaking)
SA
Aplicación Específica (Specific Application)
SASC
Caso de Seguridad para Aplicaciones Específicas (Specific Application Safety Case)
SDR
Tasa de caída segura (Safe Down Rate)
SDT
Tiempo de caída seguro (Safe Down Time)
SIL
Nivel de Integridad de Seguridad (Safety Integrity Level)
SRAC
Condiciones de la aplicación relacionadas con la seguridad (Safety-Related Application
Conditions)
TFFR
Tasa de fallo funcional tolerable (Tolerable Functional Failure Rate)
THR
Tasa de peligro tolerable (Tolerable hazard rate)
5 Proceso de seguridad
5.1
Evaluación de riesgos y control de peligros
En este apartado se introduce el modelo del reloj de arena: ofrece un enfoque simplificado que, aunque
no contiene todos los aspectos implicados en el modelo del ciclo de vida, ayuda a aclarar algunas
cuestiones.
El modelo del reloj de arena proporciona una visión general de las principales actividades
relacionadas con la seguridad que se necesitan para garantizar un nivel de seguridad aceptable para
un sistema técnico, incluyendo las áreas de responsabilidad correspondientes.
Un sistema técnico hace referencia a un producto o conjunto de productos e incluye su diseño,
implementación y documentación de soporte. El desarrollo de un sistema técnico comienza con la
especificación de sus requisitos y termina con su aceptación. El diseño de las interfaces pertinentes
tiene en cuenta las interacciones con los operadores humanos y su comportamiento, mientras que los
propios operadores humanos y sus acciones no están incluidos en un sistema técnico. Se especifican
tanto el proceso de mantenimiento (descrito en los manuales de mantenimiento) como el
funcionamiento pero no se consideran partes del sistema técnico en sí. Ambos pueden verse
restringidos por las "condiciones de la aplicación".
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 13 -
UNE-EN 50126-2:2018
El objetivo de este modelo es destacar la separación entre el análisis de riesgos como parte de la
evaluación de riesgos (a nivel del sistema ferroviario) y el análisis de peligros como parte del control
de peligros (a nivel del sistema considerado).
Esto mejora la cooperación entre las partes interesadas pertinentes, aclarando responsabilidades e
interfaces y tiene la ventaja de reducir la complejidad y facilitar la modularización.
El modelo del reloj de arena describe dos aspectos principales:
• la evaluación de riesgos, para la obtención de los requisitos de seguridad para las cuestiones
operativas y técnicas (incluido el mantenimiento), y
• el control de peligros, para cumplir los requisitos de seguridad funcional establecidos en los niveles
superiores mediante la determinación y el análisis de las causas y la concepción y aplicación de
medidas de control.
Figura 1 – Modelo del reloj de arena
NOTA La parte A (Evaluación de riesgos) está asociada con las fases 1 a 3 del ciclo de vida, tal como se muestra en la figura 4
de la Norma EN 50126-1:2017. La parte B corresponde a la fase 4 y la parte C a las fases 5 a 9. La parte D muestra la
"retroalimentación a partir de la identificación de peligros adicionales en el análisis de riesgos" (véase la figura 4 de la
Norma EN 50126-1:2017).
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
5.2
A. Evaluación de riesgos
5.2.1
Generalidades
- 14 -
La evaluación de riesgos se realiza a nivel del sistema ferroviario.
Se basa en una definición del sistema e incluye análisis y valoración de riesgos.
Define los requisitos de seguridad de alto nivel del sistema, en particular los requisitos de seguridad
para el sistema considerado desde el punto de vista del responsable del servicio ferroviario y del
operador. Tiene en cuenta los aspectos operativos relacionados con la seguridad, la experiencia previa
y los requisitos reglamentarios para la aplicación ferroviaria.
La tarea principal para esta actividad es el análisis de riesgos, que se deriva de la definición del
sistema. El análisis de riesgos incluye la identificación de peligros, el análisis de consecuencias y la
selección del principio de aceptación de riesgo (RAP).
La especificación de los requisitos de seguridad es el resultado final de la evaluación de riesgos; en la
figura 1 se asigna al cuadro B, porque constituye una interfaz (junto con las especificaciones de los
requisitos del sistema y la lista de peligros identificados) entre las diferentes responsabilidades.
5.2.2
Realización de la evaluación de riesgos
El nivel de detalle de una evaluación de riesgos debería ser el apropiado de forma que permita que se
consideren adecuadamente los riesgos. El propósito no es catalogar todos los peligros triviales, ni se
espera que siempre se identifiquen peligros más allá de los límites del conocimiento actual. La
evaluación de riesgos debe reflejar un análisis razonable de los peligros y los riesgos asociados a estos
en la operativa ferroviaria y dentro de la propia tecnología aplicada. Cuando se considere útil, las
evaluaciones de riesgos deben correlacionarse con los registros históricos de accidentes y los registros
de las causas.
Siempre que sea posible, en esta primera fase debería evitarse la consideración de la
implementación/arquitectura técnica, es decir, el sistema a desarrollar debería considerarse como una
caja negra, cuyas funciones y peligros solo se evalúan en los límites. Estos límites son interfaces bien
definidas entre el entorno operativo y el sistema en consideración.
Por ejemplo, un "movimiento involuntario del tren" es un peligro para un tren. Puede observarse como
una abstracción en el límite del "sistema tren" y podría dar lugar a distintos accidentes en función del
contexto operativo (por ejemplo, colisión en un contexto con exceso de velocidad durante la marcha o
caída de personas en relación con un tren que se mueve en una estación mientras se espera que
permanezca inmóvil, etc.).
Las hipótesis definidas durante la evaluación de riesgos deben comprobarse y actualizarse a lo largo
de las fases del ciclo de vida.
5.3
B. Resultado de la evaluación de riesgos
Los resultados de la evaluación de riesgos son un conjunto de requisitos de seguridad asociados a
funciones, sistemas o normas operativas claramente identificados. Forman parte de la Especificación
de Requisitos del Sistema que establece la interfaz técnica entre las partes interesadas.
NOTA La estructura organizativa del proyecto y las responsabilidades son otros factores a tener en cuenta en la
comprensión y control de los riesgos. Para los aspectos y requisitos organizativos se aconseja ver el capítulo 7.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 15 -
UNE-EN 50126-2:2018
En base a los principios seleccionados de aceptación de riesgos, los requisitos de seguridad pueden
referirse a Códigos de buenas prácticas, a Sistemas de Referencia o dar objetivos concretos derivados
de una Estimación explícita de los riesgos (ERE).
Los requisitos de seguridad incluyen las funciones de seguridad requeridas, que podrían evaluarse
cuantitativamente (por ejemplo, tasas máximas de peligrosidad), semicuantitativamente o
cualitativamente (por ejemplo, el uso de maquinistas con formación para controlar errores humanos).
Los requisitos de seguridad deberían evaluarse con un enfoque holístico del sistema en consideración,
es decir, el riesgo residual de todo el sistema tras la introducción de los requisitos de seguridad
debería evaluarse teniendo en cuenta todos los peligros identificados.
5.4
C. Control de peligros
La fase de control de peligros en el modelo del reloj de arena garantiza que el sistema en consideración
cumpla los requisitos de seguridad. El control de peligros se realiza para una arquitectura del sistema
específica.
Las principales repercusiones de los factores humanos, las normas operativas y generales de
mantenimiento, así como los procedimientos, forman parte del análisis de riesgos anterior y deberían
haberse tenido ya en cuenta en los requisitos de seguridad. Por tanto, durante el control de peligros, el
diseñador del sistema en consideración puede centrarse en las causas internas de los peligros
identificados.
La tarea principal es el "análisis de peligros" que comprende:
– una identificación específica de los peligros centrada en el sistema en consideración (refinamiento);
– un análisis causal;
– un Análisis de Causas Comunes (véase 11.4 para más detalles).
La identificación de peligros es una tarea recurrente, que se repite en varios niveles durante el
desarrollo del sistema en consideración. Con el fin de distinguir entre diferentes tareas (y documentos
relacionados), la identificación de peligros se cita dos veces en la figura 1:
1.
Durante la evaluación de riesgos, la identificación de peligros se centra en los peligros de alto
nivel derivados de las funciones del sistema (caja negra) y el funcionamiento relacionado del
sistema, así como de su entorno.
2.
En el marco del control de peligros, la identificación de peligros refinada/reiterada se centra en
los peligros y sus causas derivadas de las soluciones técnicas, es decir, de la arquitectura definida
y las interfaces internas del sistema en consideración, así como en los nuevos peligros potenciales
introducidos por el propio sistema.
Ambos tipos de peligros identificados deben abordarse durante el control de los peligros. La figura 2
muestra el caso general en el que la causa de un peligro a nivel del sistema ferroviario consiste en un
peligro a nivel del sistema en consideración, con respecto a su límite. El límite para la identificación del
peligro siempre se indica en la definición del sistema que limita el alcance de la tarea. Esto implica que
los peligros están estructurados jerárquicamente. Por lo tanto, debería utilizarse un enfoque
jerárquico para el análisis y registro de peligros.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 16 -
Figura 2 – Ilustración de peligros con respecto al límite del sistema
La imagen está orientada a los peligros y muestra una forma de "nudo de corbata" que sugiere que
varias causas podrían llevar al mismo peligro y que un peligro podría conducir a varios accidentes
diferentes.
EJEMPLO
El peligro a nivel del sistema ferroviario es un tren que pasa por una señal de parada y entra en el
itinerario de otro tren, lo que puede conducir a una colisión (el accidente). La causa a nivel del
sistema ferroviario (el peligro a nivel del sistema en consideración) es una distancia de frenado
demasiado larga. La causa a nivel del subsistema es que el maquinista no accionó los frenos (o se
accionaron demasiado tarde). La medida de seguridad externa la proporciona el equipo de
seguridad que ordena un frenado de emergencia.
La demostración del cumplimiento de los requisitos de seguridad del sistema en consideración puede
llevarse a cabo con distintas formas de verificación. Dichas formas dependen de la naturaleza de los
requisitos subyacentes establecidos al principio del control de los peligros.
5.5
D. Revisión de la evaluación de riesgos
Durante la fase de control de peligros, es posible que no se alcance el cumplimiento de los requisitos
de seguridad en la primera iteración. Existen tres causas potenciales:
– se identifican los peligros adicionales a nivel del sistema en consideración;
– surge la necesidad de nuevas normas de explotación;
– se requieren medidas de seguridad externas adicionales para cumplir los objetivos de seguridad.
En todos estos casos, es necesaria una revisión de la evaluación de riesgos.
Esta revisión también debería tener en cuenta las condiciones de aplicación que podrían surgir a nivel
del sistema en consideración.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 17 -
5.6
UNE-EN 50126-2:2018
Responsabilidades
La evaluación de riesgos es responsabilidad principalmente de los responsables del servicio
ferroviario y de los operadores de material rodante. Si el responsable del servicio ferroviario o el
operador no facilita ninguna evaluación de riesgos, las funciones y responsabilidades pueden
contratarse a otras partes participantes (fabricantes y proveedores), siempre que dispongan de una
serie de competencias documentadas y adecuadas para examinar detalladamente todo el contexto
operativo. Deben evaluar los riesgos resultantes de la introducción de cambios en el contexto
operativo, teniendo en cuenta los aspectos operativos relacionados con la seguridad, la experiencia
previa y los requisitos reglamentarios. En cualquier caso, los responsables del servicio ferroviario
deberían aceptar los resultados de la evaluación de riesgos.
El proveedor del sistema técnico es responsable del control de los peligros. En caso de que varios
proveedores se encarguen de distintos sistemas en consideración, el responsable del servicio
ferroviario debe hacerse responsable de organizar un control global de los peligros.
El responsable del servicio ferroviario y los proveedores deben cumplir los requisitos legales vigentes.
6 Demostración y aceptación de la seguridad
6.1
Introducción
Este apartado proporciona detalles adicionales sobre los procesos de demostración y aceptación de la
seguridad para el sistema en consideración. Salvo que se considere apropiado, no especifica quién
debería realizar el trabajo en cada etapa, ya que esto puede variar dependiendo de diferentes
circunstancias.
Las pruebas de demostración de la seguridad se basan en el caso de seguridad. La finalidad y el
contenido del caso de seguridad se definen en el capítulo 8 de la Norma EN 50126-1:2017.
En términos de procesos de seguridad, el desarrollo de un sistema puede clasificarse en tres tipos:
• Producto genérico: El sistema se considera desde un punto de vista genérico, aplicable a diferentes
clases de aplicaciones.
Los análisis se llevan a cabo en un contexto operativo independiente de la aplicación.
• Aplicación genérica: El sistema se considera adecuado para múltiples aplicaciones de la misma
clase.
Los análisis se llevan a cabo en un contexto operativo que depende de la aplicación. El proceso de
seguridad incluye la definición del proceso de diseño de la aplicación.
• Aplicación específica: El sistema se considera para una aplicación específica (incluyendo su
implementación física).
6.2
Demostración de la seguridad y proceso de aceptación de la seguridad
Se pueden definir tres categorías diferentes de casos de seguridad según el tipo de desarrollo en
cuestión, tal como se ha definido antes:
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 18 -
• Producto genérico;
• Aplicación genérica;
• Aplicación específica.
En las tres categorías, la estructura del caso de seguridad es básicamente la misma.
El caso de seguridad de la Aplicación específica debe abordar los dos aspectos siguientes:
• el diseño de la aplicación;
• la implementación física, incluyendo la fabricación, instalación y las instalaciones para operación y
mantenimiento.
Si se necesita una aceptación de seguridad distinta para el diseño de la aplicación y para su
implementación física, podría dividirse el caso de seguridad para aplicaciones específicas en dos
partes:
• el caso de seguridad del Diseño de la Aplicación;
• el caso de seguridad de la Implementación física.
El caso de seguridad, tal como se define en el capítulo 8 de la Norma EN 50126-1:2017 incluye:
– Parte 1: Definición del sistema;
– Parte 2: Informe de Gestión de la Calidad;
– Parte 3: Informe de gestión de la seguridad;
– Parte 4: Informe técnico de seguridad;
– Parte 5: Casos de seguridad relacionados (si procede);
– Parte 6: Conclusiones.
Siempre que se requiera una evaluación de seguridad independiente para el sistema en consideración,
ésta se realiza antes de la aceptación del sistema, a fin de ofrecer garantías adicionales de que se ha
alcanzado el nivel de seguridad necesario.
En este caso, la evaluación independiente de la seguridad debe tener en cuenta el caso de seguridad
relacionado con el sistema en consideración y debe realizarse de acuerdo con los requisitos definidos
en el apartado 6.8 de la Norma EN 50126-1:2017 y de acuerdo con la independencia de funciones
definida en el apartado 7.3 de la Norma EN 50126-2:2017.
La aceptación del sistema en consideración como adecuadamente seguro para su aplicación prevista
debe basarse en las siguientes condiciones:
• que haya sido desarrollado, verificado y validado de acuerdo con la serie de Normas EN 50126;
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 19 -
UNE-EN 50126-2:2018
• que los requisitos de seguridad especificados se hayan cumplido de acuerdo con la serie de Normas
EN 50126.
El conjunto de pruebas documentales para la aceptación del sistema debería consistir en:
• la definición del sistema y del contexto operativo;
• los requisitos y características del sistema, incluidos los requisitos de seguridad (y el análisis de
riesgos correspondiente cuando proceda);
• el caso de seguridad;
• el informe de evaluación independiente de la seguridad, cuando sea necesario. Dicho informe
explica las actividades realizadas para determinar si el sistema en consideración ha sido diseñado
para cumplir los requisitos de seguridad especificados y, en caso necesario, se especifican algunas
condiciones operativas adicionales.
Siempre que se cumplan todas las condiciones de aceptación de la seguridad, que se han de demostrar
en el caso de seguridad, y sujeto a los resultados de la evaluación independiente de la seguridad
cuando sea necesaria, las partes interesadas responsables de su incorporación a otro sistema o de su
uso final pueden aceptar el sistema en consideración.
Cuando se utilice un producto genérico (es decir, independiente de la aplicación) o una aplicación
genérica (es decir, la clase de aplicación) en el contexto de una aplicación específica, debería ser
posible que la aceptación de la seguridad se base en una evaluación independiente de la seguridad
relacionada existente. Esto no se considera posible para las Aplicaciones Específicas.
Cuando se desarrolle un caso de seguridad para un Producto Genérico (es decir, independiente de la
aplicación), o para una Aplicación Genérica (es decir, clase de aplicación), se debe realizar también una
actividad de validación para el sistema en consideración, que normalmente se realiza en la fase 9
"validación del sistema" del ciclo de vida del sistema, también al final de la fase 6 del ciclo de vida
"diseño e implementación", considerando también la fabricación del primer elemento.
Un ejemplo de proceso de aceptación de la seguridad, para las tres categorías del Caso de Seguridad, se
ilustra en la figura 3, donde para la Aplicación Específica se considera la referencia a Productos
Genéricos/Aplicación Genérica y a una Aplicación Específica independiente.
De acuerdo con los requisitos de adaptación definidos en la Norma EN 50126-1, las partes interesadas
responsables de un determinado proceso de seguridad deben proporcionar pruebas y justificaciones
de la cobertura y los límites de las fases del ciclo de vida cubiertas.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 20 -
Figura 3 – Ejemplo de procesos de aceptación de la seguridad
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 21 -
6.3
UNE-EN 50126-2:2018
Responsabilidad en la gestión del caso de seguridad
La responsabilidad de gestionar el caso de seguridad depende de la relación definida entre las partes
interesadas y está sujeta a acuerdos contractuales. Normalmente:
• El caso de seguridad del Producto genérico es la prueba escrita por el proveedor para la parte
responsable de configurarlo para su uso (por ejemplo, un proveedor o entidad contratante).
• El caso de seguridad de las Aplicaciones Genéricas es la prueba escrita por la parte responsable de
la configuración genérica del producto (por ejemplo, el proveedor del producto) para la parte
responsable de la configuración específica (por ejemplo, el proveedor, una entidad contratante o la
organización encargada de entregar el proyecto al operador ferroviario/administrador de
infraestructuras).
• El caso de seguridad de la Aplicación Específica es la prueba escrita por la parte que configura el
sistema para un uso específico (por ejemplo, el proveedor o la organización encargada de entregar
el proyecto al operador ferroviario/administrador de infraestructuras) para la parte responsable
del servicio ferroviario (por ejemplo, el operador ferroviario o el administrador de
infraestructuras).
A medida que el trabajo avanza de disposiciones genéricas a específicas, el argumento de seguridad
evoluciona y se basa en cada caso de seguridad anterior, por lo que el último caso de seguridad de la
aplicación específica comprende pruebas de todos los casos de seguridad relacionados. Las
condiciones de aplicación relacionadas con la seguridad se desarrollan en cada etapa y las impulsa el
siguiente actor. Por definición, el caso de seguridad para una aplicación específica y las condiciones de
aplicación relacionadas con la seguridad que define, una vez aceptadas por el operador
ferroviario/administrador de infraestructuras, se convierten en una extensión del sistema de gestión
de la seguridad del operador ferroviario/administrador de infraestructuras. A ese nivel, se evalúa si se
han cumplido todos los SRAC.
6.4
Modificaciones tras la aceptación de seguridad
Una vez que un sistema/subsistema/componente haya recibido la aceptación de seguridad, cualquier
modificación posterior se debe controlar utilizando los mismos criterios de gestión de la calidad,
gestión de la seguridad y seguridad funcional/técnica que se utilizarían para un nuevo diseño. Toda la
documentación pertinente, incluido el caso de seguridad, se debe actualizar o completar con
documentación adicional, y el diseño modificado debería estar sujeto a los procesos de aceptación en
el sistema de gestión de la seguridad del responsable del servicio ferroviario y a los procesos de
aprobación exigidos por el marco legal particular.
Una vez validado y aceptado un sistema/subsistema/componente instalado, se utilizan los
procedimientos, sistemas de soporte y control de la seguridad adecuados, que se definan en el Plan de
Seguridad, para garantizar una operación continua segura durante toda su vida útil, incluyendo la
propia operación, el mantenimiento, alteraciones, ampliaciones y la retirada final del servicio. Estas
actividades se controlan utilizando criterios de gestión de calidad, gestión de la seguridad y seguridad
técnica al menos tan seguros como los utilizados en el diseño original. El responsable del servicio
ferroviario gestiona la seguridad continua del sistema, quien debería exigir que la documentación
pertinente, incluido el caso de seguridad, se mantenga actualizada.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
6.5
- 22 -
Dependencias entre casos de seguridad
El caso de seguridad para un sistema puede depender de los casos de seguridad de otros subsistemas o
equipos. En tales circunstancias, la aceptación de la seguridad del sistema principal no es posible sin la
aceptación previa de la seguridad de los subsistemas/equipos relacionados.
La relación entre los casos de seguridad debe asociarse con la correspondiente descomposición del
sistema establecida durante la fase 2 del ciclo de vida "definición del sistema y contexto operativo".
Los diferentes tipos de Casos de Seguridad pueden definirse de acuerdo a las necesidades de
reutilización.
Si se ha obtenido un informe de evaluación independiente de la seguridad para un producto genérico o
para una aplicación genérica, puede hacerse referencia a ello para la aceptación de la seguridad de una
aplicación específica; no es necesario repetir el proceso genérico de evaluación independiente de la
seguridad para cada aplicación específica. Esta dependencia entre los casos de seguridad se ilustra con
ejemplos en la figura 4.
Un caso de seguridad puede basarse en la demostración de que la aplicación específica propuesta es
técnicamente equivalente a una aplicación existente con aceptación específica de la seguridad. Es
necesaria una nueva aceptación de la seguridad para esta aplicación específica.
Es esencial asegurarse de que las Condiciones de la Aplicación Relacionadas con la Seguridad (SRAC)
establecidas en el Informe Técnico de Seguridad de cada Caso de Seguridad se cumplen en el Caso de
Seguridad de nivel superior, o bien se trasladan a las SRAC del Caso de Seguridad de nivel superior.
EJEMPLO 1 El lado izquierdo de la figura 4 muestra un ejemplo, donde se trata un sistema ERTMS completo
para una línea específica #1 en un Caso de Seguridad de una Aplicación Específica, abarcando
también un sistema de enclavamiento ferroviario (sistema IXL #3) y un Sistema ATC #2. No se
reutiliza o se hace referencia a ningún otro Caso de Seguridad. Esto significa que los dos
subsistemas (enclavamiento y ATC) se están desarrollando dentro de esta aplicación y no dependen
de una aceptación previa.
EJEMPLO 2 El lado derecho de la figura 4 muestra un ejemplo, donde un sistema IXL para una estación
específica #4 se basa en una aplicación genérica que soporta el despliegue de una clase de
estaciones similares. A su vez, el sistema genérico IXL reutiliza un accionamiento de señal genérico.
Por tanto, el Caso de Seguridad de la Aplicación Específica se basa en dos Casos de Seguridad
Genéricos.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 23 -
UNE-EN 50126-2:2018
Figura 4 – Ejemplos de dependencias entre casos de seguridad
6.6
Relación entre los casos de seguridad y la arquitectura del sistema
No es necesario que el número, alcance y jerarquía de los diversos casos de seguridad (GPSC, GASC,
SASC) reflejen la visión arquitectónica del sistema en desarrollo, es decir, "producto genérico"
(GP),"aplicación genérica" (GA) y "aplicación específica" (SA). La arquitectura del caso de seguridad no
debe confundirse con la vista arquitectónica del "sistema", "subsistema" y "componente".
Aunque un GP (producto genérico) es a menudo un componente de una GA (aplicación genérica) o de
una SA (aplicación específica), dichos términos podrían incluso referirse al mismo elemento pero con
diferentes perspectivas.
EJEMPLO
Un componente que implementa una comunicación relacionada con la seguridad a través de un
sistema de transmisión, para intercambiar el estado de un equipo en campo:
a)
Puede considerarse como un GP (producto genérico), y estar validado/aprobado respecto a la
Norma EN 50159, si su campo de aplicación es la mitigación de amenazas genéricas a
mensajes (borrado, corrupción, resecuenciación, etc.), independientemente de su contenido.
Se definirán una serie de parámetros relacionados con la seguridad como configurables (por
ejemplo, ciclo de transmisión, duración de las interrupciones, número de respuestas).
b)
Puede considerarse como una GA (aplicación genérica), y estar validado/aprobado respecto a
un conjunto de requisitos para aplicaciones. El tipo de equipo en campo, su dinámica y cómo
se utiliza la información de estado definirán todos los parámetros de seguridad configurables a
nivel del GP (producto genérico).
c)
Puede considerarse como una SA (aplicación específica) para un lugar específico, y estar
validado para su uso específico dentro de los rangos de parámetros definidos como
condiciones de aplicación en la GA (aplicación genérica).
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 24 -
Estas etapas podrían agruparse de acuerdo con las necesidades de reutilización, por ejemplo, la etapa
a) podría ser útil si el sistema está destinado a aplicaciones completamente diferentes, de lo contrario,
los análisis relacionados con la seguridad podrían integrarse en la etapa b). Del mismo modo, la etapa
b) es aconsejable si se crean réplicas del sistema en diferentes instalaciones físicas.
7 Organización e independencia de las funciones
7.1
Generalidades
La organización, así como las funciones y responsabilidades del personal, son factores clave para
reducir los fallos sistemáticos que han de tenerse en cuenta durante todo el ciclo de vida del sistema
en consideración. El capítulo 7, con información relacionada en el anexo F para las distintas fases del
ciclo de vida, establece los requisitos específicos que han de adoptarse en las distintas fases del ciclo
de vida.
Las personas responsables de un proyecto pueden cubrir otras funciones en otros proyectos, siempre
que se ajusten a los requisitos de independencia definidos (por ejemplo, a la misma persona a la que se
asigna la función de diseñador en el proyecto A se le puede asignar la función de verificador en el
proyecto B).
Dado que las "fases iniciales" del ciclo de vida (desde la fase conceptual hasta la fase de especificación
de los requisitos del sistema) pueden estar contractualmente bajo la responsabilidad de partes
interesadas distintas a las partes interesadas de fases posteriores del ciclo de vida, el capítulo 7
diferencia los requisitos que corresponden en distintas fases.
Es decir, en los apartados 7.2 y 7.3, las funciones definidas para el diseño y desarrollo de "fases
posteriores" pueden diferir de las funciones definidas para las "fases iniciales" (por ejemplo, cuando el
proyecto se transfiere del responsable del servicio ferroviario al proveedor ferroviario o del
proveedor ferroviario a un responsable de servicios ferroviarios diferente).
También el evaluador independiente de la seguridad que participa en las "fases iniciales" puede ser
diferente del evaluador independiente de la seguridad que participa en las "fases posteriores".
Como mínimo, cada organización debe implantar un proceso, para la organización y gestión del
personal y de las responsabilidades, equivalente a los establecidos en la Norma EN ISO 9001. Este
apartado establece requisitos adicionales en materia de seguridad.
Si se requiere un evaluador independiente de la seguridad, se debe designar a un evaluador al que se
facultará para llevar a cabo la evaluación independiente de la seguridad del sistema en consideración.
El evaluador independiente de la seguridad debe ser siempre independiente del director del proyecto
y debe ser una entidad diferente de las que desempeñen otras funciones en el proyecto.
Otros requisitos reglamentarios también podrían exigir que la evaluación de la seguridad se realice de
forma independiente. Aunque dicha función podría definirse con un propósito diferente, el trabajo
debería combinarse de manera que sirva a ambos fines y evite la duplicación del trabajo.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 25 -
7.2
UNE-EN 50126-2:2018
Fases iniciales del ciclo de vida (fases 1 a 4)
En las fases iniciales del ciclo de vida (desde la fase del ciclo de vida del "concepto" hasta la fase del
ciclo de vida de la "especificación de los requisitos del sistema"), se hace hincapié en la prevención de
los fallos sistemáticos únicamente. Esto puede lograrse detectando dichos fallos mediante medidas de
control y su posterior corrección. Uno de los instrumentos principales es la verificación de los
resultados al final de cada fase del ciclo de vida. La verificación debe realizarla una entidad que no
haya participado con otras funciones en la elaboración de dichos resultados.
Los requisitos del sistema, incluidos los requisitos de seguridad, deben validarlos una entidad
competente que no haya participado en el desarrollo de los requisitos. El Validador debe indicar si los
requisitos se analizan y especifican adecuadamente para permitir que el sistema en consideración
sirva al uso o aplicación previstos.
El Validador debe ser independiente del Director de Proyecto.
El Validador puede provenir de la misma entidad que el Verificador, aunque manteniendo la
independencia del Director de Proyecto (esta opción no se muestra en la figura 5). Si el Verificador y el
Validador son la misma persona, otra persona competente con el mismo nivel de independencia que el
Validador debe revisar la información de salida de verificación y validación.
NOTA El validador necesita suficiente autonomía y responsabilidad para llegar a un juicio independiente sobre la integridad
y adecuación de los requisitos de seguridad.
Los requisitos de independencia para las fases iniciales se ilustran en la figura 5.
Figura 5 – Independencia de las funciones en las fases iniciales (fases 1 a 4) del ciclo de vida
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
7.3
- 26 -
Fases posteriores del ciclo de vida (a partir de la fase 5)
Para estas fases del ciclo de vida, el verificador debe ser competente para realizar esta función y no
debe participar en otras actividades en la misma fase del ciclo de vida, y el validador debe estar
cualificado para esta función y no debe haber participado en el diseño, en ninguna de las fases previas
del proyecto, incluida la especificación de los requisitos del sistema, la arquitectura del sistema y la
implementación del diseño del sistema.
Sin embargo, el verificador y/o el validador podrían identificar la falta de requisitos de seguridad y, a
este respecto, contribuir a la especificación de los requisitos. En este caso, un compañero debe revisar
dichos requisitos.
En función de los resultados de la evaluación de riesgos realizada en la fase 3 del ciclo de vida, se
aplican dos disposiciones alternativas (que dependen del mayor o menor nivel de gravedad de las
consecuencias o del mayor o menor nivel de integridad de la seguridad, como se define en el
capítulo 10):
• Caso (A): misma estructura de independencia que en las "fases iniciales". Esta disposición es la más
restrictiva y siempre está permitida;
• Caso (B): estructura de independencia reducida. Esta disposición está permitida a condición de que
los resultados del análisis de riesgos no hayan mostrado posibilidades directas creíbles de al menos
una víctima mortal o, cuando proceda, que el nivel de integridad de seguridad prorrateado sea
inferior o igual a SIL 2.
En el caso (A): El Validador puede provenir de la misma entidad que el Verificador, aunque debe
mantener la independencia del Director de Proyecto (esta opción no se muestra en la figura 5). Si el
Verificador y el Validador son la misma persona, otra persona competente con el mismo nivel de
independencia que el Validador debe revisar la información de salida de verificación y validación.
En el caso (B): el Validador y el Verificador pueden provenir de la misma entidad y ambos pueden
estar bajo el control directo del Director de Proyecto.
El evaluador independiente de seguridad puede formar parte de cualquier organización interesada
(por ejemplo, proveedor, administrador de infraestructura, operador de material rodante). El
evaluador independiente de seguridad debe ser siempre independiente del Director de Proyecto y
debe ser una entidad diferente de las que desempeñen otras funciones en el proyecto. El marco legal
puede exigir requisitos adicionales de independencia.
El plan de seguridad debe definir de qué manera la organización del proyecto cubre las funciones
definidas en esta norma y a quién se asignan dichas funciones. Lo ideal es que estas funciones y el
personal asignado permanezcan inalterados a lo largo de todo el proyecto de desarrollo.
Los requisitos de independencia para las fases posteriores se ilustran en la figura 6.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 27 -
UNE-EN 50126-2:2018
Figura 6 – Independencia de las funciones en las fases posteriores del ciclo de vida
(a partir de la fase 5)
7.4
Competencia del personal
Para todas las fases del ciclo de vida, las competencias clave requeridas para cada función en el
desarrollo del sistema en consideración deberían ajustarse a las indicaciones que figuran en el anexo
G. El sistema de gestión de la calidad debería definir la experiencia, las capacidades y las
cualificaciones necesarias para una función en fases específicas del ciclo de vida.
La organización responsable debería conservar pruebas documentadas de la competencia del
personal, incluyendo conocimientos técnicos, cualificaciones, experiencia relevante y formación
apropiada para demostrar una organización de seguridad apropiada.
La organización debería mantener los procedimientos de gestión de la competencia del personal para
que se adapten a las funciones apropiadas de acuerdo con las normas de calidad existentes.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 28 -
Una vez que se haya demostrado la competencia de todo el personal responsable de las funciones
descritas en los apartados 7.2 y 7.3, dichas personas deberían mostrar un mantenimiento y desarrollo
continuo de sus competencias. Esto podría demostrarse mediante un registro que documente la
actividad y la formación adicional (por ejemplo, véanse las disposiciones sobre competencias,
formación y sensibilización de la Norma EN ISO 9001).
8 Evaluación de riesgos
8.1
Introducción
La parte fundamental de la evaluación de riesgos (es decir, el análisis y la evaluación) se lleva a cabo
en la fase 3 del ciclo de vida y continúa, según proceda, a lo largo del ciclo de vida del sistema. Este
capítulo describe:
• Apartado 8.2: Análisis de riesgos con identificación de los peligros y sus consecuencias.
• Apartado 8.3: Selección de los principios de aceptación de riesgos, criterios de aceptación
relacionados y valoración de riesgos. Los principios de aceptación de riesgos son:
○ uso del código de buenas prácticas;
○ uso de un sistema de referencia;
○ uso de una estimación explícita de riesgos.
• Apartado 8.4: Aplicación de la estimación explícita de riesgos
El proceso de evaluación de riesgos puede describirse como varias tareas, como el análisis de riesgos,
la identificación de peligros, el análisis de consecuencias, la valoración de riesgos y la selección de los
principios de aceptación de riesgos.
8.2
Análisis de riesgos
8.2.1
Generalidades
Inicialmente, el análisis se realiza cualitativamente, identificando todos los factores contribuyentes y
su combinación sin cuantificación.
El proceso de análisis de riesgos es un proceso iterativo. Debe comenzar con la definición del sistema
en consideración. A continuación se deben identificar los peligros, los riesgos, las medidas de
seguridad asociadas y los requisitos de seguridad resultantes para el sistema en consideración.
El análisis de consecuencias, véase el apartado 8.2.3, implica la recopilación y documentación de datos
que describen los efectos de un peligro. El enfoque recomendado es utilizar datos sobre accidentes,
siempre que estén disponibles, y/o consultar a expertos en el entorno relacionado con el sistema o
proceso en consideración (es decir, "expertos en la materia").
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 29 -
8.2.2
UNE-EN 50126-2:2018
El modelo de riesgos
Cuando sea necesario para apoyar la identificación de peligros, la clasificación de peligros y los
principios seleccionados de aceptación de riesgos, debería definirse un modelo de riesgos. Las causas,
peligros y accidentes se encuentran en una relación de interdependencia, como por ejemplo:
• una única causa puede desencadenar (o contribuir a) varios peligros diferentes;
• un peligro puede desencadenarse por varias causas diferentes;
• un peligro puede dar lugar a diferentes tipos de accidentes en diferentes contextos operativos y
entornos;
• un accidente puede tener consecuencias diferentes en contextos operativos y entornos diferentes.
En la figura 7 se muestra un ejemplo de modelo de riesgo que indica:
• la forma en que un peligro del (sub)sistema en consideración, debido a circunstancias técnicas y
operativas, puede convertirse en un peligro a nivel del sistema ferroviario. Por lo tanto, puede
conducir a un accidente según el modelo de la figura 2, basado en los sucesos desencadenantes y las
barreras externas, si las hubiera;
• la forma en que un peligro a nivel del sistema ferroviario puede convertirse, en un determinado
contexto operativo y entorno, en un accidente con un conjunto específico de consecuencias.
Dicho modelo podría, de forma cualitativa y flexible, identificar los vínculos entre los peligros, los
sucesos desencadenantes y las medidas de protección en un escenario de accidente determinado.
En casos específicos, los peligros a nivel del sistema en consideración podrían conducir directamente a
peligros a nivel del sistema ferroviario, que podrían convertirse directamente en accidentes. En otros
casos, las medidas de protección pueden ser efectivas.
Figura 7 – Ejemplo de modelo de riesgos
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 30 -
El contexto operativo y el entorno del sistema en consideración definen dónde y cuándo un peligro a
nivel del sistema en consideración puede convertirse en un peligro a nivel del sistema ferroviario que
pueda causar un accidente. Un peligro puede convertirse en un accidente potencial diferente para
diferentes contextos operativos y/o entornos. El contexto operativo y el entorno también deberían
incluir todas las condiciones operativas o del entorno necesarias para la comprensión del escenario
del accidente.
EJEMPLO 1 Un contexto operativo puede consistir en un tren en funcionamiento normal, parado en una
estación, con embarque y desembarque de pasajeros en curso. Otros ejemplos de condiciones
operativas o del entorno son la conducción a cargo únicamente del maquinista, la pendiente de la
vía, un clima helado, un andén lleno de gente y trenes anormalmente cortos.
EJEMPLO 2 Sucesos del entorno externos, acciones humanas (por ejemplo, pasajeros que presionan los botones
de las puertas), casos específicos y fallos de sistemas externos al sistema en consideración.
El sistema en consideración está definido por el alcance del proyecto. Podría tratarse de un sistema
técnico y sus condiciones de aplicación asociadas o de un conjunto de normas y procedimientos. Este
sistema puede desencadenar peligros en determinadas circunstancias.
Dentro del sistema en consideración, los peligros pueden producirse por una combinación de:
• causas operativas (mal funcionamiento o mantenimiento) y
• causas técnicas y funcionales (internas al sistema en consideración).
Las medidas de protección externas son características técnicas u operativas ajenas al sistema
considerado que reducen la ocurrencia del peligro/accidente potencial en el sistema ferroviario o la
gravedad de las consecuencias del accidente potencial, o ambas cosas. En la figura 7, dichas medidas
de protección externas se muestran en la parte inferior en aras de la simplificación.
Dichas medidas de protección externas se deben recoger en el modelo de riesgos.
EJEMPLO 3 Frenado automático del tren inducido de forma externa en caso de exceso de velocidad causado por
una señal/indicación de velocidad incorrecta.
Las medidas de protección externas son específicas para determinados contextos operativos y
entornos, y se convierten en condiciones de aplicación relacionadas con la seguridad cuando se tienen
en cuenta en el análisis de riesgos. Por tanto, cuando se compruebe la aceptación de la seguridad del
sistema, se debe comprobar si estos casos específicos siguen siendo válidos, de lo contrario, el caso de
seguridad no será aplicable en el contexto operativo (evitando así la aceptación de la seguridad).
El peligro a nivel del sistema ferroviario es un peligro que afecta a un ferrocarril en funcionamiento
como sistema integral.
EJEMPLO 4 Para una colisión a baja velocidad, las medidas de protección externas que reducen la gravedad
podrían ser dispositivos pasivos de absorción de energía.
NOTA Las medidas de protección externas representan aquellos contextos o condiciones específicas de un escenario
determinado que reducen (o evitan) la ocurrencia del peligro que se transforma en accidente. Tales especificaciones
pueden ser, por ejemplo: factores con función neutralizadora como que solo haya un tren en la línea (por tanto, no es
posible la colisión con otro tren), velocidad limitada a 20 km/h (por tanto, las consecuencias de una
colisión/descarrilamiento pueden ser menores), sólo tráfico de mercancías (por tanto, no hay víctimas entre los
pasajeros).
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 31 -
UNE-EN 50126-2:2018
EJEMPLO 5 La tabla 1 muestra ejemplos de peligros funcionales / técnicos con o sin medidas de protección
externas.
Tabla 1 – Ejemplos de peligros
Peligro a nivel
del sistema en
consideración
Pérdida de la
capacidad de
frenado
Medidas de
protección
externas que
reducen la
frecuencia
Accidente
potencial
Medidas de
protección
externas que
reducen la
gravedad
Consecuencias
del posible
accidente
Rebasamiento de la
distancia de frenado
No existen
medidas de
protección
Múltiples víctimas
mortales o lesiones
graves
Información
No existen
equivocada en una medidas de
señal
protección
Rebasamiento de
Colisión
señal con indicación
de parada
No existen
medidas de
protección
Múltiples víctimas
mortales o lesiones
graves
Fallos técnicos en
la protección de
un paso a nivel
Paso a nivel sin
protección
8.2.3
No existen
medidas de
protección
Peligro a nivel del
sistema
ferroviario
Se detecta un
fallo en la
protección de
un paso a nivel
y se muestra al
maquinista
Colisión con El conductor de Múltiples víctimas
un conductor un vehículo por mortales o lesiones
de vehículo carretera
graves
por carretera detecta la falta
de protección
del paso a nivel
y se detiene
antes del paso
Técnicas para el análisis de consecuencias
Debido a la complejidad de los escenarios a analizar, el análisis de consecuencias se realiza utilizando
técnicas ascendentes o una combinación de técnicas ascendentes y descendentes.
El juicio de expertos es fundamental para el análisis y la calibración de las técnicas utilizadas como
apoyo.
Se pueden utilizar diferentes técnicas, a menudo combinadas, para realizar el análisis de
consecuencias. A continuación se enumeran brevemente las técnicas utilizadas normalmente:
• Análisis por Árbol de Eventos.
• Análisis por árbol de fallos (AAF).
• Análisis de modos de fallo, de sus efectos y de su criticidad (FMECA, Failure Mode Effect & Criticality
Analysis).
• Diagrama causa-efecto.
• Estudio de peligros y operatividad (HAZOP, Hazard and operability study).
En el anexo F figura una lista de las diversas técnicas y métodos utilizados durante las fases del ciclo de
vida.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 32 -
No siempre es posible comprobar/estimar los riesgos de los sistemas de una manera matemática
basada en datos fiables.
Inicialmente, el análisis se realiza cualitativamente, identificando todos los factores contribuyentes y
su combinación sin cuantificación.
Si se adopta una estimación explícita de riesgos, será posible calcularlo utilizando la frecuencia de las
incidencias y la gravedad de sus consecuencias (adecuada al sistema analizado).
Las frecuencias y la gravedad pueden expresarse cuantitativa y/o semicuantitativamente, por ejemplo,
con los términos "improbable", "frecuente", "lesiones leves", "víctimas" (véase la Norma EN 50126-1
para ejemplos de estas clases).
8.2.4
Juicio de expertos
Si un enfoque cuantitativo para la estimación explícita de riesgos no es viable porque no se dispone de
la información necesaria, se requiere el juicio de expertos en el enfoque cualitativo. También se puede
utilizar el juicio de expertos para el enfoque cuantitativo.
EJEMPLO
Información no disponible, como datos, conexiones causales e interrelaciones/interacciones entre
los componentes del sistema.
En algunos casos, el juicio de los expertos puede ser el único enfoque si no se pueden producir datos
fiables.
Para que sea una base creíble para la evaluación de riesgos, la opinión de los expertos debería ser lo
más objetiva posible. Esto implica:
• Las comprobaciones/estimaciones no deberían ser las opiniones de una sola persona. El acuerdo
entre varios expertos (independientes) y los conocimientos aprobados aumentan la confianza en
una evaluación.
• Los expertos han de tener conocimientos adecuados del tema en cuestión.
• El juicio de los expertos debería comprender todas las áreas de conocimiento necesarias (que
podrían incluir diferentes clasificaciones).
• Si se aplica el juicio de expertos para estimar la frecuencia y las consecuencias de los peligros (o de
los accidentes), una comprensión clara de las categorías promueve una interpretación común.
• Los resultados del juicio de los expertos se han de documentar. Esto garantiza la transparencia y
plausibilidad de las conclusiones. Demuestra la integridad y permite a terceros hacer un
seguimiento de las conclusiones.
• La documentación se perfecciona cuando se dispone de nueva información.
La documentación debería incluir:
• a los participantes y sus respectivas áreas de especialización.
• información como referencias a publicaciones, fuentes, supuestos, aspectos deliberadamente
excluidos y su justificación, justificación de la conclusión, etc.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 33 -
8.3
Principios de aceptación de riesgos y valoración de riesgos
8.3.1
Uso del código de buenas prácticas
UNE-EN 50126-2:2018
Los códigos de buenas prácticas (CoP), cuando se aplican correctamente, pueden utilizarse para
controlar uno o más peligros específicos. La aplicación de códigos de buenas prácticas puede utilizarse
como principio de aceptación de riesgos. Cada código de buenas prácticas debe cumplir los siguientes
requisitos:
• ser un conjunto de normas ampliamente reconocido en el ámbito ferroviario. De no ser así, se debe
justificar el uso de dicho código de buenas prácticas y;
• ser pertinente para el control de peligros en el sistema en consideración.
EJEMPLO 1 Para las transmisiones relacionadas con la seguridad a través de sistemas de comunicación no
seguros, podría aplicarse como código de buenas prácticas la Norma EN 50159.
EJEMPLO 2 La Norma EN 50153: Aplicaciones ferroviarias. Material rodante. Medidas de protección relativas a
riesgos eléctricos.
Si uno o más peligros se controlan mediante códigos de buenas prácticas que cumplan los requisitos
anteriores, los riesgos asociados a estos peligros se deben considerar aceptables. Esto significa que
estos riesgos no han de analizarse más a fondo.
El uso de los códigos de buenas prácticas se debe registrar en el registro de peligros como requisitos
de seguridad para los peligros pertinentes.
Si uno o más peligros están controlados por códigos de buenas prácticas, no es necesario aplicar otros
principios de aceptación de riesgos para estos peligros.
Si la aplicación de un código de buenas prácticas no puede cubrir de manera aceptable el riesgo de un
peligro concreto, se deben determinar medidas de seguridad adicionales aplicando otros principios de
aceptación de riesgos. Esto también puede ocurrir cuando el código de buenas prácticas
correspondiente no cubre suficientemente los peligros identificados (por ejemplo, el código de buenas
prácticas no es aplicable a toda la gama de peligros).
8.3.2
Uso de un sistema de referencia
El sistema en consideración puede compararse con un sistema de referencia para la evaluación de
riesgos. La aplicación de códigos de un sistema de referencia puede utilizarse como principio de
aceptación de riesgos.
El sistema de referencia similar debe cumplir los siguientes requisitos:
• que haya demostrado que tiene un nivel de seguridad aceptable y que, por tanto, seguiría siendo
apto para su aprobación;
• que tiene funciones e interfaces similares a las del sistema en consideración;
• que se ha utilizado en condiciones operativas similares a las del sistema en consideración durante
un período de tiempo suficiente y ha dado confianza en la serie de riesgos y accidentes analizados;
• se utiliza en condiciones de entorno similares a las del sistema en consideración.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 34 -
NOTA Este enfoque implica que la información anterior se haya registrado para el proyecto que ha introducido el sistema de
referencia y que la información se ha conservado.
Si un sistema de referencia cumple los requisitos enumerados anteriormente, entonces para el sistema
en consideración:
• los riesgos asociados a los peligros cubiertos por el sistema de referencia se deben considerar
aceptables;
• los requisitos de seguridad para los peligros cubiertos por el sistema de referencia se deben derivar
de los análisis de seguridad o de una evaluación de los registros de seguridad del sistema de
referencia;
• estos requisitos de seguridad deben registrarse en el registro de peligros como requisitos de
seguridad para los peligros pertinentes.
Si el sistema objeto de evaluación se desvía del sistema de referencia, la valoración de riesgos debe
demostrar que el sistema objeto de evaluación alcanza al menos el mismo nivel de seguridad que el
sistema de referencia, aplicando otro sistema de referencia o uno de los otros dos principios de
aceptación de riesgos. En ese caso, se deben considerar aceptables los riesgos asociados a los peligros
cubiertos por el sistema de referencia.
Si no puede demostrarse al menos el mismo nivel de seguridad que el sistema de referencia, se deben
identificar medidas de seguridad adicionales para las desviaciones, aplicando uno de los otros dos
principios de aceptación de riesgos.
8.3.3
Uso de una estimación explícita de riesgos
Si los peligros no están cubiertos por uno de los dos principios de aceptación de riesgos del apartado
8.3.1 o del apartado 8.3.2, el análisis de riesgos se debe llevar a cabo utilizando el principio de
aceptación de riesgos de estimación explícita de riesgos junto con la valoración de riesgos.
La estimación explícita de riesgos evalúa el riesgo proveniente de un peligro de un sistema en un
contexto operativo particular. El objetivo es estimar el riesgo y asegurar que el riesgo sea aceptable.
La estimación explícita de riesgos debe cumplir los siguientes requisitos:
• los métodos utilizados deben reflejar correctamente el sistema en consideración y sus parámetros
(incluidos todos los modos de funcionamiento);
• los resultados deben ser lo suficientemente precisos como para servir de apoyo sólido a la toma de
decisiones. Los cambios menores en los supuestos o prerrequisitos de entrada no deben dar lugar a
requisitos significativamente diferentes.
Deben documentarse los resultados de la estimación explícita de riesgos.
La estimación puede hacerse cuantitativa y/o cualitativamente:
• La estimación cuantitativa explícita de riesgos se realiza estimando la frecuencia de ocurrencia y la
gravedad de un escenario de accidente. Esto se debe hacer para las consecuencias de todos los
escenarios peligrosos identificados, utilizando datos y/o el juicio de expertos.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 35 -
UNE-EN 50126-2:2018
• La estimación cualitativa explícita de riesgos se debe realizar utilizando el juicio de expertos (por
ejemplo, utilizando un argumento lógico basado en la definición del sistema).
Las frecuencias y la gravedad pueden estimarse usando métodos semicuantitativos o cuantitativos.
Cuando se utilice el principio de estimación explícita de riesgos, debe:
• definir los criterios de aceptación de riesgos que han de utilizarse para establecer la aceptabilidad
del nivel de riesgo para las consecuencias de los peligros pertinentes;
• demostrar que las medidas de seguridad aplicadas son capaces de reducir el riesgo para cumplir los
criterios de aceptación de riesgos.
Si el riesgo asociado a un peligro o a una combinación de varios peligros se considera aceptable, las
medidas de seguridad identificadas se deben registrar en el registro de peligros.
Existen diferentes métodos para obtener el nivel de riesgo aceptable, basados en requisitos legales o
de otro tipo.
EJEMPLO 1 Requisitos legales vigentes, normas técnicas existentes, sistemas o procesos de seguridad
existentes. Estos criterios no se establecen en esta norma europea.
El anexo A describe algunos métodos conocidos para definir los criterios de aceptación de riesgos.
Cuando se aplica una estimación explícita de riesgos, los responsables del servicio ferroviario pueden
asignar objetivos de seguridad para los peligros a nivel del sistema ferroviario.
EJEMPLO 2 Véase el Ejemplo 1 en el capítulo C.4 de la Norma EN 50126-1:2017.
El objetivo de seguridad cuantitativo expresado como THR (tasa de peligro tolerable) para un peligro
determinado debería referirse a funciones elementales específicas sin tener en cuenta el número de
casos en todo el sistema ferroviario. De este modo se evitará que un sistema técnico determinado que
cumpla una THR definida y ya haya sido aceptado deje de considerarse aceptable cuando aumente el
número de casos.
Las unidades para estos objetivos de seguridad pueden variar. Cuando, como resultado del análisis de
riesgos, se transfieran estos objetivos al sistema técnico en forma de tasa de peligro tolerable (THR),
se debe producir una transformación, ya que la THR se debe expresar en unidades por hora (h-1).
Si el responsable del servicio ferroviario no proporciona las THR, trabajará conjuntamente con el
proveedor para definir los requisitos o el proveedor podría proponerlos.
8.4
Aplicación de la estimación explícita de riesgos
8.4.1
Enfoque cuantitativo
8.4.1.1
Generalidades
El enfoque cuantitativo implica la elaboración de elementos del modelo de riesgos utilizando técnicas
para estimar los riesgos.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 36 -
Estos enfoques pueden utilizarse para establecer objetivos numéricos para su aplicación a
subproyectos, sistemas y subsistemas y también para demostrar que dichos objetivos se han
alcanzado posteriormente.
El análisis por árbol de fallos se utiliza comúnmente para calcular la frecuencia de ocurrencia de
peligros, así como el análisis por árbol de eventos para calcular la probabilidad de que estos peligros
conduzcan a accidentes. Existen muchas maneras y enfoques híbridos en los que tales técnicas (u
otras) pueden combinarse y estructurarse para calcular las estimaciones de riesgo.
Los objetivos de seguridad en caso de accidente proporcionan entradas de información para los
modelos de riesgos. Por consiguiente, pueden utilizarse para derivar o validar una tasa de peligro
tolerable, véase la figura 8.
La figura 8 muestra el caso de una tasa de peligro tolerable en el escenario de un accidente. La tasa de
peligro tolerable es aplicable a un peligro técnico específico del sistema en consideración.
Figura 8 – Tasas tolerables asignadas en un ejemplo de modelo de riesgos
Existen áreas en las que el enfoque cuantitativo no suele ser viable y la estimación y los argumentos de
aceptación de riesgos pueden seguir siendo cualitativos, por ejemplo:
• partes mecánicas que dependan de la resistencia de los materiales y de las propiedades de
tolerancia de diseño a lo largo de la vida útil del producto;
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 37 -
UNE-EN 50126-2:2018
NOTA Si se aplica una estimación explícita de riesgos a las partes mecánicas, la estimación se centrará probablemente en la
parte constante de la curva de la función de fallo. Esto no excluye la necesidad de considerar la gestión de fallos en el
"período de fallo inicial" y la "fase de desgaste" de la vida útil del producto.
• peligros eléctricos que dependan de medidas técnicas para evitar la electrocución, las tensiones
inducidas, etc.
• normas de explotación (incluido el personal de explotación, los trabajadores de mantenimiento,
etc.), en las que podría ser difícil demostrar que se han cumplido las tasas de peligros tolerables
(THR);
• peligros relacionados con lesiones leves de los pasajeros por contacto con bordes afilados, tropiezo
en superficies resbaladizas;
• peligro de incendio/explosión que dependan de medidas técnicas para su prevención.
8.4.1.2
Objetivos de seguridad en caso de accidente
Los objetivos de seguridad en caso de accidente se refieren a un accidente potencial:
• que se produzca en el marco de un contexto operativo y
• un entorno concreto y
• causado por un peligro identificado a nivel del sistema ferroviario.
Los objetivos de seguridad en caso de accidente pueden especificarse (para un sistema en
consideración) en su contexto operativo y entorno específicos mediante el uso de:
• objetivos de seguridad de alto nivel que pueda establecer la autoridad responsable de la seguridad
dentro del marco legal;
• modelos, datos o análisis existentes adecuados derivados de accidentes que se hayan producido
anteriormente y su gravedad;
• datos, modelos o información adecuados sobre los índices de peligrosidad, en particular sobre los
peligros que se hayan demostrado relevantes.
Las estadísticas de seguridad acumulativa pueden tratar un conjunto de sistemas diferentes y
diferentes escenarios de accidentes. Por lo general, la autoridad responsable de la seguridad o el
responsable del servicio ferroviario debe establecer esta relación al fijar objetivos para escenarios de
accidentes específicos. Para ello, las estadísticas de accidentes han de contener suficiente información
contextual y técnica para poder establecer la pertinencia para un proyecto determinado (véase, por
ejemplo, el anexo B).
Esta norma no requiere establecer una relación entre los objetivos de seguridad en caso de accidente y
las estadísticas nacionales de seguridad acumulativas.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
8.4.1.3
- 38 -
Tasa de peligro tolerable (THR)
La tasa de peligro tolerable (THR) puede obtenerse para el sistema en consideración a través de
análisis de ingeniería, estudios y acuerdos entre el responsable del servicio ferroviario y el proveedor
ferroviario.
Los objetivos acumulativos deben distribuirse entre el sistema en consideración en su contexto
operativo y el entorno específico. En particular, un objetivo de seguridad acumulativo para un
accidente causado por diferentes peligros se debe distribuir adecuadamente entre los diversos
peligros que lo causen.
El responsable del servicio ferroviario también puede asignar directamente la tasa de peligro tolerable
a los peligros técnicos como objetivo a alcanzar por el proveedor ferroviario.
Se pueden tener en cuenta las medidas de protección externas entre los peligros técnicos y los
accidentes potenciales. La reducción del riesgo que proporciona una medida de protección puede
depender del contexto operativo.
NOTA Para ilustrar la posible dependencia de la reducción de riesgos del contexto operativo, la medida de protección "corte
de tracción cuando las puertas del tren estén abiertas" solo es efectiva cuando el tren esté parado porque impide que
el tren se mueva cortando la energía de tracción. Por lo tanto, esta medida de protección puede considerarse como
una medida de protección para otras funciones, pero no proporciona ningún factor de reducción de riesgos cuando el
tren está en marcha.
La división descrita de los objetivos de seguridad en caso de accidente entre la tasa de peligro
tolerable es un enfoque descendente. De forma alternativa, puede seguirse un método ascendente,
empezando por una tasa de peligro tolerable y verificando que se alcancen los objetivos de seguridad
en caso de accidente.
Si la tasa de peligro tolerable se deriva de un objetivo de seguridad en caso de accidente, se debe
analizar toda la cadena de accidentes. Los riesgos aceptables se deben distribuir entre los distintos
tipos de accidentes y los distintos peligros funcionales y operativos, a fin de alcanzar un nivel
aceptable de seguridad para todo el sistema ferroviario.
8.4.1.4
Responsabilidades
El responsable del servicio ferroviario debería:
• especificar la tasa de peligros tolerables, para que el diseñador del sistema pueda determinar si el
diseño de su sistema es capaz de cumplir los criterios;
• determinar los requisitos cuantitativos de seguridad a nivel del sistema ferroviario. El responsable
del servicio ferroviario puede trabajar junto con el proveedor ferroviario para definir la tasa de
peligros tolerables a nivel de peligros técnicos;
• definir el sistema en consideración y su contexto operativo y entorno, y proporcionar esta
información al proveedor ferroviario junto con la tasa de peligros tolerables asociada a los peligros
identificados.
El responsable del servicio ferroviario y el proveedor ferroviario deberían ponerse de acuerdo sobre la
lista de peligros asociados con el sistema en consideración:
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 39 -
UNE-EN 50126-2:2018
• los peligros conocidos por cualquiera de las partes se han de comunicar a todas las partes
interesadas para ayudar a garantizar que se tienen en cuenta;
• el responsable del servicio ferroviario puede hacer suposiciones razonables sobre la frecuencia
alcanzable de ocurrencia de peligros asociados con el sistema técnico en su fijación de objetivos,
evaluación de riesgos y actividades de gestión de la seguridad;
• el proveedor ferroviario es consciente del contexto operativo en el que se producen los peligros, así
como de otros peligros ajenos al sistema técnico que podrían ser relevantes, de modo que el
proveedor ferroviario pueda tenerlos en cuenta en el diseño del sistema.
El proveedor ferroviario
• puede revisar los supuestos y confirmar su validez para el sistema en desarrollo.
• demostrará que las tasas de peligro estimadas para el diseño cumplen con la tasa de peligros
tolerables, posiblemente bajo una serie de supuestos realizados para apoyar el análisis, y en la
hipótesis de que todas las mitigaciones asumidas se aplicarán posteriormente.
Todos los supuestos establecidos por el proveedor ferroviario deben documentarse y transmitirse al
integrador o al responsable del servicio ferroviario como condiciones de aplicación. El usuario debe
aceptar estas condiciones de aplicación y posteriormente aplicarlas. Para el diseño de un producto,
sistema, subsistema, hardware o software genérico para una amplia gama de aplicaciones, no se puede
definir el contexto específico. Por tanto, el diseñador del sistema debería hacer suposiciones sobre el
uso operativo del sistema y su entorno, sus riesgos técnicos y accidentes potenciales. El diseñador
debe asignar una tasa de peligros tolerables a los peligros técnicos. Estos supuestos forman parte de
las condiciones de aplicación para el uso del sistema (incluidas las condiciones operativas y de
mantenimiento).
8.4.2
Variabilidad utilizando estimaciones de riesgo cuantitativas
8.4.2.1
Generalidades
Los métodos utilizados ofrecen estimaciones aproximadas de los niveles de riesgo generados por los
peligros. Los resultados obtenidos con estos métodos deberían usarse teniendo en cuenta las
incertidumbres inherentes.
En las fases iniciales del ciclo de vida del proyecto cuando se asignan los requisitos de seguridad (fases
1 a 3), un alto nivel de incertidumbre en las estimaciones de riesgo es una circunstancia importante a
tener en cuenta a la hora de asignar los requisitos de seguridad. La gestión de estas incertidumbres de
manera adecuada es parte fundamental del proceso de gestión de riesgos.
Se pueden utilizar los siguientes enfoques:
• "peor caso posible", en el apartado 8.4.2.2, o
• "estimaciones razonables", en el apartado 8.4.2.3, o
• "peor caso razonable", en el apartado 8.4.2.4.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 40 -
Otro enfoque posible es analizar los peligros en escenarios con mayores o menores consecuencias, por
ejemplo, en casos de colisión a alta velocidad y colisión a baja velocidad en los que se generen
diferentes series de requisitos de seguridad asociados al peligro global. Esto reduce el rango de
incertidumbres de los riesgos para cada serie de requisitos de seguridad.
8.4.2.2
"Peor caso posible"
El enfoque más conservador para tratar las incertidumbres es tratar con el peor caso posible. Esto se
hace durante el proceso de asignación de requisitos (en la fase 3 del proceso del ciclo de vida).
Dependiendo de los datos de proyecto específicos disponibles, el enfoque del "peor caso posible"
podría aplicarse como se indica a continuación (es decir, el caso con el riesgo más elevado):
• se supone que si un peligro puede conducir a un número posible de accidentes, se debería utilizar el
peor caso posible en el análisis (es decir, el caso con el riesgo más elevado);
• si se estima la frecuencia con la que ocurre un peligro como un rango basado en un análisis
estadístico de datos, se ha de utilizar entonces la frecuencia más elevada en el análisis;
• si se estima el efecto de un riesgo mediante el juicio de expertos, entonces se ha de adoptar la
evaluación del peor caso posible emitida por los expertos.
8.4.2.3
"Estimaciones razonables"
La metodología recomendada para gestionar la incertidumbre de los datos es utilizar estimaciones
razonables a lo largo del proceso de gestión de riesgos, incluso para establecer objetivos de seguridad
(tasas de peligro tolerable al nivel más elevado del sistema).
Estas estimaciones pueden incluir la posibilidad de un peligro particular basado en el perfil operativo,
teniendo en cuenta todos los factores que podrían incrementar o reducir la gravedad de un accidente,
incluyendo acciones humanas.
Las estimaciones de frecuencia y consecuencias pueden basarse en:
• los datos recogidos en los sistemas ferroviarios existentes;
• la extrapolación de datos de situaciones similares en otros sistemas ferroviarios o incluso en otros
sistemas de transporte, el cálculo de las tasas de fallo utilizando herramientas de predicción
genéricas de tasas de fallo;
• el dictamen de expertos.
Al final del proceso, se puede realizar una estimación de la incertidumbre, teniendo en cuenta que las
diferentes incertidumbres de las estimaciones individuales pueden restarse o añadirse.
Esta estimación puede utilizarse para ajustar objetivos o modificar los criterios de aceptación como
una tolerancia de seguridad razonable.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 41 -
8.4.2.4
UNE-EN 50126-2:2018
"Peor caso razonable"
Un enfoque intermedio entre el "peor caso posible" y las "estimaciones razonables" es el "peor caso
razonable". Se trata de aplicar el peor caso a uno de los factores dominantes en el análisis de seguridad
para introducir medidas conservadoras razonables. Por tanto, las "estimaciones razonables" deben
aceptarse en el resto de factores dominantes, de lo contrario, el análisis completo se convertiría en un
análisis del "peor caso".
8.4.3
Enfoques cualitativos y semicuantitativos
En un método semicuantitativo o cualitativo, la estimación explícita del riesgo se lleva a cabo
utilizando el juicio para asignar la frecuencia y la gravedad a categorías predefinidas que pueden ser
de naturaleza más o menos numérica.
Este enfoque es particularmente útil en la fase inicial del ciclo de vida del proyecto, cuando se dispone
de pocos análisis o información. En esta etapa, la categorización de los peligros es útil para determinar
sus riesgos relativos y centrar la atención.
En el anexo C de la Norma EN 50126-1:2017 figuran ejemplos y directrices para la calibración de las
categorías de frecuencia de accidentes y de las categorías de gravedad y la matriz de tolerancia a
riesgos.
9 Especificación de los requisitos de seguridad del sistema
9.1
Generalidades
Una función, componente, producto, sistema o procedimiento se denomina relacionado con la
seguridad si al menos una de sus propiedades se utiliza en el argumento de seguridad del sistema en el
que se aplica. Estas propiedades pueden ser de naturaleza funcional o no funcional.
Estar "relacionado con la seguridad" significa que se le han asignado uno o más requisitos de
seguridad. Esto es el resultado del análisis de riesgos y de la valoración de riesgos, que comprende la
aceptabilidad de las medidas de control y de los riesgos residuales.
El proceso de evaluación de riesgos debe dar lugar a un conjunto de requisitos de seguridad del
sistema acordados entre las partes interesadas. Los requisitos de seguridad pueden estar contenidos
en una especificación de requisitos de seguridad separada o estar etiquetados como "requisitos de
seguridad" en la especificación de requisitos del sistema.
9.2
Requisitos de seguridad
En la especificación de los requisitos de seguridad se debe tener en cuenta lo siguiente:
– las funciones relacionadas con la seguridad;
– los supuestos relacionados con la seguridad, como la eficacia (probabilidad de fallo bajo demanda,
por hora, etc.) de las medidas de mitigación (por ejemplo, sistemas de protección, redundancias);
– las tasas de peligro tolerable (THR) o la tasa de fallo funcional tolerable (TFFR) para los requisitos
cuantitativos, si se definen durante la estimación explícita de riesgos, teniendo en cuenta:
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 42 -
○ la definición de estados seguros,
○ la definición del tiempo máximo permitido para entrar en un estado seguro,
○ medidas, equipos o dispositivos de detección de fallos;
– los requisitos derivados del análisis de peligros realizado en el nivel superior;
– la adaptación a interfaces;
– las normas de organización;
– las normas de explotación;
– las normas de mantenimiento;
– las condiciones del entorno;
– los requisitos de seguridad legales.
9.3
Categorización de los requisitos de seguridad
9.3.1
Generalidades
Los requisitos de seguridad se pueden clasificar de la siguiente manera:
– requisitos de seguridad funcional (9.3.2);
– requisitos de seguridad técnica (9.3.3);
– requisitos de seguridad contextual (9.3.4).
Figura 9 – Clasificación de los requisitos
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 43 -
9.3.2
UNE-EN 50126-2:2018
Requisitos de seguridad funcional
Después de realizar el análisis de riesgos, una función puede identificarse como "relacionada con la
seguridad" y asignarse con requisitos de seguridad funcional.
NOTA Puede ocurrir que una función, considerada inicialmente como posiblemente relacionada con la seguridad, al final del
análisis de riesgos no cuente con ningún requisito de seguridad: por ejemplo, porque el peligro relacionado con ella se
atenúa por otros medios o porque se considera ampliamente aceptable. En este caso, la función se considerará no
relacionada con la seguridad.
Si no se utiliza ninguna propiedad de la función para alcanzar y demostrar la seguridad, y no se dan
requisitos de seguridad, la función no está relacionada con la seguridad y no son necesarias medidas
adicionales para la aprobación de la seguridad.
Los requisitos de seguridad funcional deben incluir:
– el comportamiento funcional esperado de las funciones relacionadas con la seguridad;
– el comportamiento de las funciones relacionadas con la seguridad en caso de fallo, dividido en:
a)
los requisitos de integridad de seguridad requeridos,
b) el comportamiento requerido en caso de fallo no peligroso (es decir, aplicación y
mantenimiento del estado seguro).
La integridad de la seguridad se refiere a la capacidad de un sistema relacionado con la seguridad para
cumplir las funciones de seguridad requeridas. Cuanto mayor sea la integridad de la seguridad, menor
será la probabilidad de que no lleve a cabo las funciones de seguridad requeridas.
La integridad de la seguridad de la función puede verse afectada tanto por fallos aleatorios como
sistemáticos; por lo tanto, la integridad de seguridad comprende dos partes: integridad de la seguridad
sistemática y aleatoria.
La prevención de fallos sistemáticos y aleatorios puede requerir diferentes enfoques:
– la integridad de seguridad aleatoria se logra mediante el diseño del producto (por ejemplo,
diversidad, redundancia, protección contra las condiciones previstas del entorno en códigos de
buenas prácticas específicos, etc.);
– la integridad de la seguridad sistemática puede beneficiarse de los mecanismos técnicos
incorporados en un producto (por ejemplo, la diversidad), pero se basa principalmente en
soluciones de proceso, como la gestión de la calidad, la gestión de la seguridad y las medidas
organizativas.
Las acciones de sustitución podrían ser suficientes en caso de causas aleatorias. Sin embargo, en caso
de fallos debidos a errores sistemáticos, la sustitución del elemento defectuoso solo puede
proporcionar una primera respuesta y podrían ser necesarias otras medidas correctoras.
Cuando existen modelos de fallos bien definidos y bases de datos comunes, se puede realizar una
evaluación cuantitativa para el aspecto del fallo aleatorio de la integridad de seguridad.
En la actualidad no existe una base comúnmente aceptada para cuantificar los fallos sistemáticos. Por
tanto, los métodos definidos en esta norma excluyen la cuantificación de fallos sistemáticos.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
9.3.3
- 44 -
Requisitos de seguridad técnica
Los requisitos técnicos de seguridad están relacionados con el diseño técnico y la implementación del
sistema.
Los requisitos técnicos de cada subsistema/producto pueden derivarse de diferentes aspectos, como la
mantenibilidad, las condiciones del entorno y las amenazas potenciales creadas por la tecnología, el
sistema o el subsistema, independientemente de sus funciones previstas.
EJEMPLOS
Peligros de incendio, peligros interiores tales como bordes afilados, presencia de tensión eléctrica,
presencia de material combustible, peligros relacionados con la integridad estructural, presencia de
agentes/sustancias nocivas, resistencia mecánica, comportamiento inseguro en condiciones físicas
como humedad, calor, fuego, etc.
Los requisitos técnicos de seguridad incluyen limitaciones técnicas para el diseño, la instalación o el
uso, como la coordinación de aislamiento, la puesta a tierra y la compatibilidad electromagnética.
Pueden incluir requisitos de seguridad como:
– la conformidad con normas externas,
– la normativa pertinente,
– códigos de buenas prácticas.
9.3.4
Requisitos de seguridad contextual
Los requisitos de seguridad contextuales cubren los requisitos de seguridad operativos y de
mantenimiento.
Los operadores deberían garantizar la implementación de los requisitos de seguridad operativa,
incluidos los siguientes:
– las acciones específicas previstas para cualquier categoría de personal;
– los procedimientos operativos previstos en modos de funcionamiento normal y anormal;
– las suposiciones sobre las restricciones operativas relacionadas con la seguridad;
EJEMPLO 1 Velocidad, número de trenes en circulación, tiempo medio de servicio, instrucciones de
señalización.
– reglas de la interfaz humana.
EJEMPLO 2 Demanda de formación, demanda de personal, conjunto de competencias disponibles del personal
de explotación.
Los requisitos de seguridad de mantenimiento consisten en una lista de acciones de mantenimiento
relacionadas con la seguridad, tales como:
• mantenimiento
○ intervalos,
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 45 -
UNE-EN 50126-2:2018
○ normas,
○ procedimientos para aplicaciones específicas,
○ series de ensayos y comprobaciones de seguridad antes de volver a poner un sistema en servicio
después de someterlo a tareas de mantenimiento;
• limitaciones
○ de las condiciones de almacenamiento de las piezas de repuesto,
○ sobre el tipo de herramientas utilizadas,
○ sobre las características físicas de las herramientas a utilizar.
10 Distribución de los requisitos de integridad de la seguridad funcional
10.1 Obtención y distribución de los requisitos de seguridad del sistema
Este apartado describe cómo se distribuyen los diferentes tipos de requisitos de seguridad estipulados
en el capítulo 9 entre la arquitectura del sistema durante la fase 5 del ciclo de vida (arquitectura y
distribución de los requisitos del sistema) y la fase 6 (diseño e implementación).
Se proporcionan directrices para proceder con las funciones implementadas mediante:
– la arquitectura electrónica (véase 10.2);
– la arquitectura no electrónica (véase 10.3).
10.2 Integridad de la seguridad funcional de los sistemas electrónicos
10.2.1
Obtención de requisitos de seguridad funcional para sistemas electrónicos
Este apartado se centra en los requisitos de seguridad para las funciones electrónicas (o partes
electrónicas de funciones complejas realizadas con diversas tecnologías). Se muestra cómo gestionar
los requisitos de seguridad funcional al transformarlos en una arquitectura de sistema conforme y al
asignar un SIL (nivel de integridad de la seguridad) a las funciones a nivel de subsistema y aplicar
medidas de seguridad.
El SIL no debe utilizarse para la seguridad no funcional. El SIL asignado a un equipo mecánico o
electromecánico se debe considerar no aplicable y se debe indicar así en el proceso de demostración,
ya que esta norma solo introduce medidas y técnicas para sistemas electrónicos.
NOTA Por lo que se refiere a los requisitos de seguridad técnica, como las condiciones climáticas o la compatibilidad
electromagnética, la aplicación de un código de buenas prácticas es un enfoque bien establecido.
10.2.2
Distribución de los requisitos de seguridad
Durante la fase 5 del ciclo de vida "distribución de los requisitos del sistema", los requisitos de
seguridad del sistema se reparten entre los subsistemas y/o componentes designados.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 46 -
El proceso de distribución de los requisitos relacionados con la seguridad entre los componentes del
sistema considerado se define como "control de peligros". Contiene la evaluación de posibles peligros
y la asignación de requisitos de integridad de seguridad a las funciones relacionadas con la seguridad.
La figura 10 muestra la distribución de los requisitos de seguridad funcional relacionados con el
control de peligros.
Figura 10 – Distribución de los requisitos de seguridad funcional
Inicialmente, los requisitos de integridad de seguridad, expresados a nivel de sistema para cada
peligro como THR (tasa de peligro tolerable), están vinculados a una composición funcional específica
definida por la arquitectura del sistema elegida y, por tanto, se traducen en TFFR (tasa de fallo
funcional tolerable) para las funciones. La distribución de la tasa de peligro tolerable (THR) se realiza
mediante análisis causal utilizando diversos métodos como el árbol de fallos y teniendo en cuenta las
interdependencias lógicas entre los subsistemas o funciones.
La relación entre el peligro y las funciones puede no ser unívoca. La causa de un peligro puede ser el
fallo no seguro de una o más funciones. En caso de una sola función de protección contra peligros, se
considera que el requisito cuantitativo de integridad de la seguridad (THR) está asignado
completamente a dicha función.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 47 -
UNE-EN 50126-2:2018
NOTA Si el fallo de una función puede provocar una situación de peligro, o si la función deja de proporcionar protección
contra el peligro, se dice que se trata de un fallo funcional no seguro.
Si la relación entre peligro y funciones es unívoca, para cada peligro con su objetivo cuantitativo
correspondiente, el requisito de integridad de la seguridad cuantitativo (expresado como THR, tasa de
peligro tolerable) se debe asignar completamente a la función que protege contra ese peligro (TFFR,
tasa de fallo funcional tolerable).
De no ser así, en caso de combinación de funciones múltiples, la THR (tasa de peligro tolerable) debe
distribuirse entre los subpeligros y sus tasas de fallos funcionales tolerables hasta el nivel de las
últimas funciones independientes. Este es el nivel en el cual dos (o más) funciones controlan el mismo
peligro en este nivel (véase el punto a.), siendo sin embargo completamente independientes (véase el
punto b.).
Por "nivel de las últimas funciones independientes" se entiende:
a. que cualquiera de ellas es capaz de contrarrestar el peligro en este nivel, independientemente de la
presencia o ausencia de la otra función, aunque con diferente eficacia;
EJEMPLO Las medidas de protección y las señales luminosas en el paso a nivel pueden funcionar de manera
diferente en función del peligro de atravesar el paso cuando éste esté cerrado.
b.
que ningún fallo de causa común aleatorio puede poner en peligro la seguridad y que ningún fallo
de causa común sistemático puede poner en peligro la seguridad como se indica en la figura 12.
Esto debe demostrarse mediante un Análisis de Fallos de Causa Común y todas las suposiciones hechas
se deben documentar adecuadamente y se deben exportar si es necesario. Además, en las fases
posteriores debe demostrarse que la implementación sigue los principios de diseño estipulados y los
supuestos aplicados. Especialmente para las "puertas Y" dentro de un modelo, se debe detallar cómo
se consigue la tasa de peligro tolerable global, incluidos los factores que contribuyen de las
subfunciones (por ejemplo, los requisitos de detección y anulación).
En lo que respecta a la causa común de los fallos y a los distintos tipos de independencia, se aplica lo
siguiente:
• La ausencia de fallos aleatorios comunes que pongan en peligro la seguridad.
○ Implica que, a un determinado nivel arquitectónico de implementación, el conjunto de
elementos que conforman esta arquitectura no falla de manera crítica, simultánea o en cascada,
como consecuencia de una causa física común.
○ Cualquier conexión física, interacción o influencia física común (recursos físicos compartidos,
flujo de energía, entorno común) puede llevar a una causa física común que ponga en peligro la
seguridad.
• La ausencia de fallos sistemáticos comunes que pongan en peligro la seguridad.
○ Implica que ninguna causa relacionada con el proceso impida la identificación de fallos que
puedan heredar el potencial de fallos de causa común. Se considera que la independencia
organizativa (véase el capítulo 7) y la diversidad en los recursos humanos y en los procesos del
ciclo de vida contribuyen a una mayor integridad general de la seguridad de los productos y
sistemas.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 48 -
○ Cualquier actividad de proceso común en las fases de diseño, fabricación, instalación y
mantenimiento (por ejemplo, el mismo recurso humano, un modelo común, etc.) puede ser
causa de errores comunes durante la fase de desarrollo de las dos funciones.
• Ausencia tanto de fallos aleatorios comunes como de fallos sistemáticos comunes que pongan en
peligro la seguridad.
El resultado del análisis de causas comunes es la demostración de independencia o la comprensión de
las causas comunes (críticas) existentes. Estas deberían tenerse en cuenta en análisis posteriores de la
siguiente manera:
– Si se garantiza la ausencia de fallos de causa común críticos, tanto sistemáticos como aleatorios,
entre dos o más funciones electrónicas, la tasa de fallo funcional tolerable (TFFR) puede
distribuirse más detalladamente y el nivel de integridad de la seguridad (SIL) puede asignarse al
nivel más bajo de estas funciones (véase 10.2.8).
– Si se garantiza solo la ausencia de fallos aleatorios comunes, los requisitos de integridad aleatoria
(tasa de fallos) se pueden distribuir al siguiente nivel arquitectónico inferior de implementación,
pero el nivel de integridad de la seguridad (SIL) permanece inalterado (véase 10.2.9).
TFFR es una tasa. En caso de que se den probabilidades de fallo bajo demanda, estas probabilidades
pueden transformarse en modelos apropiados de modo continuo.
La tasa de peligro tolerable (THR) es un requisito tanto para los fallos sistemáticos como para los
aleatorios, sin embargo:
– se acepta que sólo es posible cuantificar fallos aleatorios y verificar teóricamente que se cumple el
requisito de la tasa de fallo funcional tolerable (véase 10.2.10);
– también son necesarias medidas cualitativas como protección contra fallos aleatorios y
sistemáticos. Esto está cubierto por las medidas obtenidas del nivel de integridad de la seguridad,
como se describe con más detalle en el apartado 10.2.6.
En un refinamiento del control de peligros (después de la asignación del nivel de integridad de la
seguridad (SIL), cuando la función relacionada con la seguridad se distribuye en varias subfunciones,
véase el apartado 10.2.8), la tasa de fallo funcional tolerable (TFFR) se distribuye más detalladamente,
lo que da lugar a tasas de fallo para los subsistemas/elementos.
El nivel de integridad de la seguridad (SIL) se mantiene inalterado en estos niveles más bajos de
distribución para el desglose funcional así como para la integración de las subfunciones, ya que no se
puede demostrar ninguna independencia completa adicional, véase el apartado 10.2.9.
La distribución de la integridad de la seguridad funcional también puede basarse en enfoques
cualitativos (véase 10.2.7).
Esto se describe con más detalle en los anexos D y E.
10.2.3
Factores de integridad de la seguridad
La integridad de la seguridad de la función en general expresa la confianza depositada en el
cumplimiento y mantenimiento de los requisitos de seguridad.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 49 -
UNE-EN 50126-2:2018
La integridad de la seguridad puede verse afectada por fallos aleatorios y sistemáticos. Expresa el nivel
de confianza de que alguno de ellos corrompe el cumplimiento del requisito de seguridad.
Las condiciones del entorno deberían incluirse en los aspectos sistemáticos de la integridad de la
seguridad, según proceda.
10.2.4
Integridad de la seguridad funcional y fallos aleatorios
Cuando se defina una tasa de fallo funcional tolerable (TFFR), se deben establecer los demás requisitos
cuantitativos y cualitativos pertinentes para cada función, a fin de cumplir el objetivo de tasa de
peligro tolerable (THR) definido en el nivel de peligro.
De hecho, la tasa de fallo funcional tolerable (TFFR) no es suficiente para caracterizar una función
relacionada con la seguridad. El modelo de fallo funcional necesario y el diseño arquitectónico deben
hacer referencia a:
– los fallos funcionales no seguros;
– el modo en que el sistema puede detectar una avería si es necesario;
– los principios de diseño de seguridad que garanticen una reacción segura;
– el tiempo de caída seguro (SDT, véase D.3.1 del anexo D) si es necesario en el modelo;
– el modo en que la función sale del estado de fallo, por ejemplo, restaurando o entrando en un
estado seguro;
– el modo en que contiene el sistema los efectos de las averías (recuperación del sistema,
procedimientos de emergencia);
– las acciones de procedimiento y mantenimiento que han de implementarse y la periodicidad de las
mismas.
También deberían tenerse en cuenta las funciones auxiliares (diagnóstico) y el mantenimiento
preventivo.
10.2.5
Aspecto sistemático de la integridad de la seguridad funcional
Los procesos de calidad y seguridad tienen como objetivo prevenir y reducir las averías sistemáticas a
causa del diseño. Esto debería incluir errores humanos en todas las fases, no solo en la fase de diseño.
Una gestión eficaz de la seguridad es esencial para minimizar las averías sistemáticas durante todas las
fases del ciclo de vida.
10.2.6
Requisitos equilibrados para el control de fallos aleatorios y sistemáticos
La integridad de la seguridad de una función aborda diferentes aspectos, cada uno de ellos necesario
para proporcionar confianza en el cumplimiento de los requisitos. El objetivo cuantitativo de
seguridad es solo uno de los aspectos de la integridad de la seguridad que ha de cumplirse.
Es decir, además de los aspectos cuantitativos, la integridad de la seguridad también aborda factores
como la gestión de la calidad, la gestión de la seguridad y las medidas técnicas de seguridad.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 50 -
En esta norma se abordan "medidas cualitativas" como:
– las condiciones de gestión de la calidad;
– las condiciones de gestión de la seguridad;
– medidas de seguridad técnica.
Cuanto más riguroso sea el requisito cuantitativo expresado como TFFR (tasa de fallo funcional
tolerable), más estrictas serán las medidas cualitativas. Para equilibrar las medidas cualitativas y la
TFFR (tasa de fallo funcional tolerable), se definen las medidas básicas y cuatro niveles de integridad
de seguridad, desde el SIL 1 al 4 (el nivel más alto de integridad de la seguridad), véase el apartado
10.2.8.
NOTA En otras normas se pueden tratar conceptos similares del SIL (nivel de integridad de la seguridad). La comparación de
estos SIL (niveles de integridad de la seguridad) requiere un análisis más profundo.
La integridad de la seguridad requiere que un conjunto de "medidas cualitativas" esté correlacionado
con una serie de TFFR (tasa de fallo funcional tolerable). Las medidas detalladas se pueden definir en
normas sectoriales específicas.
Todos los factores de la figura 11 se deben cumplir para alcanzar la integridad de seguridad
especificada:
– el objetivo de seguridad cuantificado particular;
– las condiciones de gestión de la calidad, las condiciones de gestión de la seguridad y las medidas
técnicas de seguridad asociadas a un nivel de integridad de la seguridad determinado.
Figura 11 – Categorización de las medidas de integridad de la seguridad
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 51 -
10.2.7
UNE-EN 50126-2:2018
Tabla de niveles de integridad de la seguridad (SIL)
La siguiente tabla de niveles de integridad de la seguridad (SIL) define el nivel de integridad de la
seguridad (SIL) necesario basado en la tasa de fallo funcional tolerable (TFFR) para una función
electrónica relacionada con la seguridad, véase el apartado 10.2.8. Así pues, si la TFFR (tasa de fallo
funcional tolerable) de una función se ha obtenido mediante un método cuantitativo, el SIL (nivel de
integridad de la seguridad) requerido se debe determinar utilizando la tabla 2.
También cuando se realiza una distribución puramente cualitativa, por ejemplo, mediante un Gráfico
de Riesgos, es necesario seleccionar un objetivo cuantitativo de la TFFR (tasa de fallo funcional
tolerable) dentro del rango de niveles de integridad de la seguridad obtenido.
NOTA El conjunto de medidas cualitativas pertinentes que han de aplicarse a cada SIL (nivel de integridad de la seguridad)
entra en el campo de aplicación de las normas de sectores específicos.
Tabla 2 – Medidas cuantitativas y cualitativas del nivel de integridad de la seguridad (SIL)
TFFR [h-1]
Asignación de nivel de integridad Medidas cualitativas del nivel de
de la seguridad (SIL)
integridad de la seguridad (SIL)
10-9 ≤ TFFR < 10-8
4
10-8 ≤ TFFR < 10-7
3
10-7 ≤ TFFR < 10-6
2
10-6 ≤ TFFR < 10-5
1
Definidas en normas específicas
para cada sector industrial
En caso de que la TFFR (tasa de fallo funcional tolerable) obtenida sea más exigente (inferior) que
10-9 [h-1], la función debe tratarse de una de las siguientes maneras:
– si es posible dividir la función en funciones completamente independientes, la TFFR (tasa de fallo
funcional tolerable) puede distribuirse entre esas funciones y se puede asignar un SIL (nivel de
integridad de la seguridad) a cada función;
– si la función no puede dividirse, al menos se deben cumplir las medidas y métodos del nivel de
integridad de la seguridad SIL 4 y la función se debe utilizar en combinación con otras medidas
técnicas u operativas para lograr la TFFR (tasa de fallo funcional tolerable) necesaria.
En caso de que la TFFR (tasa de fallo funcional tolerable) obtenida sea menos exigente (superior) que
10-5 [h-1], se debe asignar a la función el atributo de "integridad básica", con los requisitos relacionados
definidos en el apartado 10.2.11.
El concepto y los requisitos de integridad básica también pueden utilizarse para funciones no
relacionadas con la seguridad.
10.2.8
Asignación de nivel de integridad de la seguridad (SIL)
Para las funciones que controlan el mismo peligro, los niveles de integridad de la seguridad (SIL) se
deben asignar de acuerdo con la tasa de fallo funcional tolerable (TFFR) (como se indica en el apartado
8.2.2). Esto puede hacerse en el nivel más bajo, donde las funciones identificadas son completamente
independientes, véanse los criterios de los puntos a. y b. del apartado 10.2.2.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 52 -
Para una función de control de peligros múltiples, si la obtención de la distribución de la TFFR (tasa de
fallo funcional tolerable) y la subsiguiente asignación del SIL (nivel de integridad de la seguridad) (de
acuerdo con el apartado 10.2.7) se realizan por separado para cada peligro (según se indica en el
apartado 8.2.2), se debe aplicar el requisito más restrictivo.
10.2.9 Distribución de la TFFR (tasa de fallo funcional tolerable) después de la asignación del
SIL (nivel de integridad de la seguridad)
Después de la asignación del SIL (nivel de integridad de la seguridad) en el último nivel independiente
(es decir, el nivel más bajo cuando las funciones son completamente independientes), cuando la
función relacionada con la seguridad se distribuye en varias subfunciones (posiblemente asignadas en
diferentes sistemas/subsistemas), la TFFR (tasa de fallo funcional tolerable) se distribuye de nuevo, lo
que lleva a tasas de fallo para las subfunciones, pero en este nivel físico o de implementación, las
subfunciones no se asignan con otro SIL (nivel de integridad de la seguridad) diferente.
El SIL debe permanecer asociado a la función relacionada con la seguridad a la que pertenecen las
subfunciones. En consecuencia, las medidas cualitativas del nivel de integridad de la seguridad (SIL) se
deben aplicar según el nivel de integridad de la seguridad (SIL) definido en el nivel al que pertenece la
subfunción.
El proceso de distribución de la tasa de fallo funcional tolerable (TFFR) puede realizarse mediante
cualquier método que permita una representación adecuada de la lógica de combinación, por ejemplo,
diagramas de bloques de fiabilidad, árboles de fallos, diagramas de decisión binarios, modelos de
Markov, redes de Petri, etc. En cualquier caso, hay que tener especial cuidado cuando se requiere
independencia en el sentido de ausencia de fallos críticos, sistemáticos y aleatorios comunes de los
elementos.
Se deben comprobar las suposiciones realizadas en esta fase y podrían dar lugar a condiciones de
aplicación relacionadas con la seguridad.
10.2.10 Demostración de objetivos cuantificados
Para demostrar el cumplimiento de los objetivos cuantificados, solo se tienen en cuenta los fallos
aleatorios en la evaluación de la tasa de fallo funcional tolerable (TFFR) y de la tasa de peligro
tolerable relacionada (THR).
Los fallos sistemáticos han de controlarse mediante el proceso adecuado y los requisitos cualitativos
estipulados por las medidas cualitativas del nivel de integridad de la seguridad (SIL) y por lo tanto no
están contribuyendo al cálculo ni cumplimiento cuantitativo de los requisitos de integridad de la
seguridad requeridos.
Por tanto, habiendo seguido las medidas y métodos requeridos para los niveles de integridad de la
seguridad SIL 1-4, no es necesario considerar los fallos sistemáticos cuando se logra demostrar
teóricamente la tasa de fallo funcional tolerable (TFFR).
10.2.11 Requisitos para la integridad básica
Para las funciones relacionadas con la seguridad que se clasifican con el atributo de "integridad
básica", véase el apartado 10.2.7, se aplican los siguientes requisitos a nivel de sistema cuando la
función está integrada:
NOTA Los requisitos específicos para la "integridad básica" pueden definirse también mediante normas de sectores
industriales específicos.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 53 -
UNE-EN 50126-2:2018
– En las "fases iniciales", es decir, las fases 1 a 4 del ciclo de vida antes de ser clasificadas con el
atributo de "integridad básica", la función se debe evaluar en el proceso de análisis de riesgos y los
resultados se deben recoger en el registro de peligros. Se aplican los requisitos de independencia
adecuados.
– En la fase 5 del ciclo de vida ("diseño del sistema"), se deben tomar las medidas adecuadas de
gestión de averías, como diagnósticos, mantenimiento, formación de los operadores y
procedimientos adecuados.
– En la fase 8 del ciclo de vida ("fase de integración"):
○ cualquier suposición (no trivial) hecha en el proceso de asignación de requisitos de seguridad se
debe registrar como condición de aplicación relacionada con la seguridad (SRAC);
○ la función se debe incluir en el ensayo de validación del sistema (incluido el análisis de impacto
en otras funciones del nivel de integridad de la seguridad, SIL);
○ se debe demostrar la ausencia de intrusismo (es decir, ausencia de efectos retroactivos, es decir,
que la función no afecte a otras funciones relacionadas con la seguridad).
– En la fase 9 del ciclo de vida ("validación"), el caso de seguridad debe abordar la función
relacionada con la seguridad.
– En la fase 11 del ciclo de vida ("fase operativa"), un seguimiento debe garantizar que la función de
integridad básica siga funcionando hasta la retirada del servicio (inspecciones de mantenimiento
para comprobar que se alcanza el objetivo de fallo aleatorio).
Para el desarrollo de la función clasificada con el atributo de "integridad básica" se aplican los
siguientes requisitos:
– Evidencia de la seguridad:
○ No se requiere ninguna demostración adicional de seguridad durante las fases de diseño y
desarrollo, salvo la demostración del objetivo cuantitativo.
– Evidencia de la calidad:
○ En lo que respecta a la integridad sistemática, se deben aplicar medidas de calidad adecuadas.
Basta con un proceso de gestión de calidad según la Norma EN ISO 9001 y la Norma
ISO/IEC 90003 aplicado por el proveedor. Sin embargo, más que una etiqueta de conformidad
con la Norma EN ISO 9001, en el informe de gestión de calidad del sistema debe tenerse en
cuenta una demostración eficaz de la conformidad con la Norma EN ISO 9001.
○ Se requieren formación y manuales de mantenimiento para el operador.
– Requisitos organizativos
○ El verificador y validador deben ser diferentes del Diseñador2), pero no se requiere la
independencia organizativa de los equipos.
2) Este requisito es más restrictivo que los de la Norma EN ISO 9001.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 54 -
– Siempre que la evaluación independiente de la seguridad haya confirmado que la asignación de
Integridad Básica es adecuada (no se requiere un nivel de integridad de la seguridad SIL más alto
para alcanzar los requisitos de seguridad), no se requiere ninguna otra evaluación independiente
de la seguridad.
– Una autoevaluación del cumplimiento de esta norma y de las normas específicas del sector es
aceptable para demostrar el cumplimiento de los requisitos de integridad básica.
– Caso de seguridad
○ No se requiere un Caso de seguridad o un Informe técnico de seguridad para la función de
Integridad Básica en sí.
10.2.12 Prevención del uso incorrecto de los SIL (niveles de integridad de la seguridad)
Este apartado proporciona advertencias sobre el uso de los SIL (niveles de integridad de la seguridad)
en sistemas electrónicos.
NOTA A veces se malinterpreta el concepto de SIL (nivel de integridad de la seguridad) y se utilizado en aplicaciones no
deseadas.
La siguiente lista no exhaustiva ofrece consejos sobre cómo no deberían utilizarse los SIL (niveles de
integridad de la seguridad):
– Los SIL (niveles de integridad de la seguridad) deberían asignarse a nivel de la última función
independiente solo después de un análisis de riesgos en las fases apropiadas del ciclo de vida de
acuerdo con uno de los principios de aceptación de riesgos u obtención equivalente. No tiene
sentido asignar un SIL (nivel de integridad de la seguridad) antes de completar tal análisis.
– Los SIL (niveles de integridad de la seguridad) no deberían utilizarse para la seguridad no
funcional, por ejemplo, aplicar un SIL (niveles de integridad de la seguridad) a seguridad contra
resbalones, tropezones y caídas.
– El cumplimiento de todos los requisitos de integridad cuantitativos y cualitativos no garantiza que
la función correspondiente esté correctamente definida.
– Los SIL (niveles de integridad de la seguridad) no deberían utilizarse para describir los atributos de
los sistemas, por ejemplo, "este es un ordenador SIL 4". La redacción correcta sería: "se trata de un
ordenador capaz de realizar las funciones especificadas SIL 4 relacionadas con la seguridad,
siempre que se apliquen todas las SRAC (condiciones de la aplicación relacionadas con la
seguridad) asociadas a este ordenador".
10.3 Integridad de la seguridad para sistemas no electrónicos. Aplicación del Código
de buenas prácticas
Este apartado contiene requisitos técnicos para las partes no electrónicas de funciones relacionadas
con la seguridad. Se trata de indicaciones sobre cómo tratar los requisitos técnicos de los sistemas no
electrónicos.
Para estos sistemas, la aplicación de un Código de buenas prácticas (CoP) es un enfoque bien
establecido. Alternativamente, es posible utilizar los métodos descritos en las correspondientes
normas tecnológicas específicas.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 55 -
UNE-EN 50126-2:2018
EJEMPLOS de sistemas no electrónicos en el contexto de esta norma (no exhaustivos):
• sistemas mecánicos, por ejemplo, puertas, ventanas, fuelles, pasarelas, conductos de cables, soportes, etc.;
• sistemas neumáticos, por ejemplo, compresores, mangueras, tuberías, válvulas, actuadores;
• sistemas hidráulicos, por ejemplo, bombas, mangueras, tuberías, válvulas, actuadores.
Los sistemas no electrónicos a menudo se diseñan de acuerdo con uno o más Códigos de buenas
prácticas.
Si se aplica un Código de buenas prácticas para diseñar una función relacionada con la seguridad o
para lograr las características de seguridad específicas de un sistema, esto se considera suficiente para
reducir el riesgo residual a un nivel aceptable para los peligros abordados por el Código de buenas
prácticas.
Incluso si el Código de buenas prácticas no se ocupa específicamente de los peligros, se debe
comprobar y justificar que el Código de buenas prácticas se aplica para cubrir los peligros.
El Código de buenas prácticas se debe aplicar según sea necesario y debe cumplir los requisitos del
apartado 8.3.1.
Si el Código de buenas prácticas no recomienda o requiere métodos específicos para un análisis de
fallos, se pueden seleccionar técnicas adecuadas del anexo F.
Debe prestarse especial atención a las causas de los fallos de los sistemas y funciones no electrónicos
debidos a las propiedades físicas inherentes que afectan al final de la vida útil:
○ desgaste mecánico, degradación o fatiga (por ejemplo, número de ciclos de trabajo de un eje,
diámetro mínimo de la rueda);
○ influencia del entorno (por ejemplo, estrés térmico, sol, contaminación, degradación química del
caucho o material plástico).
Los efectos relacionados pueden minimizarse o evitarse mediante la aplicación correcta del Código de
buenas prácticas y mediante medidas apropiadas de garantía de calidad durante las fases de diseño, la
fabricación y el mantenimiento:
○ fin prematuro de la vida útil debido a una aplicación inadecuada o a un mantenimiento insuficiente
(por ejemplo, grietas, corrosión);
○ manipulación incorrecta que provoque defectos en los componentes (por ejemplo, rotura de
clavijas, fugas, etc.).
En la mayoría de los casos, la aplicación de un Código de buenas prácticas no proporciona información
sobre la frecuencia esperada de fallos aleatorios de las funciones y sistemas no electrónicos. Si estos
sistemas y funciones se incluyen en los análisis cuantitativos de fallos (por ejemplo, AAF), se debería
tener especial cuidado en la modelización correcta de su frecuencia de fallos, teniendo en cuenta el
posible desgaste, el mantenimiento preventivo y los datos de campo.
Además de la aplicación de un Código de buenas prácticas, se deben tomar medidas para evitar fallos
sistemáticos en la medida en que sean aplicables a los sistemas no electrónicos.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 56 -
NOTA Esta norma no permite la asignación de niveles de integridad de la seguridad a funciones no electrónicas. Los SIL
(niveles de integridad de la seguridad) solo se definen para funciones que dependen de sistemas electrónicos (o para
la parte electrónica de una función electromecánica).
11 Diseño e implementación
11.1 Introducción
Este apartado proporciona orientación sobre las fases 5 y 6 del ciclo de vida (véanse 7.6 y 7.7 de la
Norma EN 50126-1:2017).
Durante estas fases, se debe llevar a cabo un análisis de peligros que comprenda un análisis causal, una
identificación más precisa de los peligros y un análisis de causas comunes.
11.2 Análisis causal
El análisis causal es la investigación sistemática de la jerarquía de las causas derivadas de la solución
técnica. El objetivo es identificar las secuencias lógicas de eventos peligrosos que pueden conducir a
un efecto no deseado.
Durante el análisis causal se debe identificar lo siguiente:
– cualquier función, fallo del sistema o del subsistema, error humano creíble y/o factores externos
creíbles (permanentes o no) que puedan causar peligros técnicos;
– todas las normas de operación y medidas de protección de seguridad que puedan fallar en la
protección contra un peligro.
El análisis causal consiste en:
– la identificación de todos los factores causales: del entorno, funcionales, de interfaz, hardware,
software, humanos;
– la identificación de la relación lógica entre causa y efecto teniendo en cuenta los peligros en el
límite del sistema en consideración;
– la identificación de la combinación de eventos o mecanismos que vinculan la causa con el efecto (es
decir, el peligro);
– la identificación y modelización de fallos de causa común mediante la aplicación de análisis de
causa común.
Las técnicas de análisis causal tienen como objetivo identificar la secuencia lógica de los eventos que
se convierten en un peligro. El análisis puede realizarse cualitativa o cuantitativamente, utilizando un
enfoque descendente. Para escenarios complejos, la investigación de la secuencia lógica causa-efecto
se completa utilizando una combinación de técnicas ascendentes o técnicas mixtas ascendentes y
descendentes. Las técnicas típicas de análisis causal son:
– Análisis por árbol de fallos (AAF);
– FMECA (Análisis de los modos de fallo, efectos y criticidad);
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 57 -
UNE-EN 50126-2:2018
– análisis de Markov;
– Análisis por Árbol de Eventos;
– análisis de los factores humanos.
11.3 Identificación de peligros (refinamiento)
La realización de un sistema puede dar lugar a propiedades imprevistas o indeseables que pueden
causar daños a las personas, en particular si el sistema o la tecnología son nuevos. Los peligros
imprevistos pueden surgir debido a varios aspectos:
– una nueva tecnología tiene el potencial de crear nuevos peligros, que no pudieron identificarse
inmediatamente debido a la falta de experiencia o conocimientos;
– la aparición de peligros adicionales en el sistema existente debido a una transferencia tecnológica
(por ejemplo, de la tecnología analógica a la digital);
– errores en el nuevo diseño debido a la falta de especificaciones adecuadas;
– los modos de operación especiales en un sistema existente podrían no encajar bien y pueden crear
nuevos peligros asociados a acciones realizadas por operadores, encargados de mantenimiento u
otros miembros del personal, el público, etc.;
– los errores de diseño pueden crear nuevos peligros, pero a menudo pueden estar relacionados con
peligros ya identificados.
Estos aspectos pueden dar lugar a posibles causas de peligros a nivel del sistema en consideración, que
requieren el mismo tratamiento sistemático que el aplicado a los peligros ya identificados a nivel del
sistema ferroviario. Entonces es posible proceder de, al menos, dos maneras diferentes:
– si el peligro en el nivel del sistema en consideración puede considerarse como una nueva causa de
un peligro ya identificado, el proveedor ferroviario debería asegurarse de que la tasa de peligro
resultante, teniendo en cuenta también las nuevas causas, sigue cumpliendo con la tasa de peligro
tolerable (THR) fijada por el responsable del servicio ferroviario;
– si el peligro en el nivel del sistema en consideración conduce a un nuevo peligro, o supera la tasa de
peligro tolerable (THR), el proveedor ferroviario lo debe comunicar al responsable del servicio
ferroviario y le debe proporcionar toda la información del análisis de peligros (causas,
consecuencias, riesgos). A continuación, el responsable del servicio ferroviario debería analizar
estas nuevas condiciones. Dependiendo de los riesgos percibidos, se requiere una evaluación
cualitativa o cuantitativa, con vistas a prever y acordar un nivel tolerable apropiado (THR, tasa de
peligro tolerable). Esto podría llevar a la actualización de requisitos.
En ambos casos, todas las acciones deben recogerse en el registro de peligros y mencionarse en el caso
de seguridad.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 58 -
11.4 Análisis de causas comunes
La sección de fallos de causa común en la parte izquierda de la figura 12 designa el subconjunto de
fallos que causan que tanto la función A como la función B fallen simultáneamente. Por tanto, estos
fallos de causa común pueden modelarse por separado, tal y como se muestra en el árbol de fallos a la
derecha de la siguiente figura, mediante una puerta O.
Estos fallos de causa común se deben modelar utilizando las reglas combinatorias lógicas adecuadas
para garantizar que no se cuenten varias veces.
Figura 12 – Impacto de la dependencia funcional en un análisis de árbol de fallos
Cuando se detecte un fallo de causa común, se debe aplicar una de las siguientes opciones:
– cambiar el diseño para eliminar el fallo de causa común;
– asegurarse de que la THR (tasa de peligro tolerable) es aceptable, incluyendo este fallo de causa
común.
A efectos de evaluar la independencia entre dos o más elementos de un sistema, el análisis de causa
común debe incluir la identificación tanto de las interfaces externas como de las internas:
– las interfaces externas son las que se establecen entre el sistema en consideración y las entidades
externas;
– las interfaces internas son las que se establecen entre los elementos del sistema en consideración.
En estas interfaces se deben tomar medidas para evitar influencias no intencionadas, teniendo en
cuenta las causas comunes que pueden afectar tanto a la independencia física como a la lógica.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 59 -
UNE-EN 50126-2:2018
Anexo A (Informativo)
ALARP, GAME, MEM
A.1 ALARP, GAME, MEM como métodos para definir los criterios de aceptación
de riesgos
Para aplicar el principio de aceptación de riesgos "estimación explícita de riesgos", es necesario definir
el nivel aceptable de riesgo. Existen diferentes métodos y maneras de obtener y expresar el nivel
aceptable de riesgo para los peligros pertinentes.
En las siguientes secciones se describen tres métodos para definir los criterios de aceptación de
riesgos en caso de estimación explícita de riesgos.
La demostración de que el nivel de riesgo alcanzado es aceptable ha de ajustarse al marco legal
pertinente y la aplicación de cualquiera de estos principios ha de tenerlo en cuenta. En este contexto,
el uso de tales principios puede proporcionar una base para establecer los niveles de aceptación de
riesgos. Sin embargo, a falta de disposiciones u orientaciones legales o de otro tipo, la elección del
principio dependerá, en gran medida, del entorno social y político imperante. Por tanto, todas las
partes interesadas deberían acordar la elección y el uso de estos principios. La tabla A.1 proporciona
una visión general sobre los métodos descritos más adelante en detalle.
Tabla A.1 – Descripción general de ALARP, GAME, MEM
Criterios
ALARP
GAME
MEM
Enfoque general
Impone una obligación relativa,
Comparación de dos
estableciendo que el responsable
sistemas: el nuevo sistema
del servicio ferroviario debería
tiene que ser globalmente
aplicar cualquier medida de
tan seguro o más seguro
seguridad que reduzca el riesgo
que el existente.
ALARP (a un nivel tan bajo como
sea razonablemente práctico). Si se
considera que los costes de una
medida no son desproporcionados
con respecto a los beneficios para
la seguridad, teniendo en cuenta
cualquier incertidumbre en las
estimaciones del riesgo, se
considera que la medida es
necesaria para reducir el riesgo
ALARP (a un nivel tan bajo como
sea razonablemente práctico).
Cálculo del riesgo
aceptable basado en la
tasa más baja de
mortalidad de individuos
humanos en la población
general.
Referencia del
riesgo
El cambio en el riesgo colectivo
asociado con cada opción/medida
de seguridad.
Normalmente a un riesgo
individual.
Sistema de referencia.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
Criterios
- 60 -
ALARP
GAME
MEM
Supuestos
Supone una cierta ponderación
relativa y valoración del daño
asociado con diferentes tipos y
niveles de gravedad de
lesiones/víctimas.
Un sistema similar al
nuevo ha de existir ya;
requiere analizar el
sistema existente
(antiguo); entonces se
puede aplicar el método
GAME.
Han de realizarse otras
hipótesis sobre la
distribución de riesgos
entre los subsistemas y
componentes.
Criterios de
aceptación
Si se considera que los costes de
una medida son
desproporcionados con respecto a
los beneficios para la seguridad,
teniendo en cuenta cualquier
incertidumbre en las estimaciones
del riesgo, se considera que la
medida no es necesaria para
reducir el riesgo ALARP (a un nivel
tan bajo como sea razonablemente
práctico).
El nuevo sistema es menos El riesgo individual
arriesgado o igual que el
(víctimas por persona y
sistema existente
tiempo) causado por el
(antiguo).
sistema es menor que el
riesgo tolerable derivado
del método MEM.
Área de aplicación Evaluación de la seguridad de los
proyectos. Es necesario seguir
trabajando para asignar posibles
controles de seguridad a peligros
si se va a utilizar el enfoque para
establecer la THR (tasa de peligro
tolerable).
Establecer objetivos
cuantitativos de riesgo
para los sistemas;
construir argumentos
cualitativos de seguridad;
comparar dos o más
sistemas equivalentes
(equivalencia funcional o
técnica).
Establecer objetivos
cuantitativos de riesgo
para sistemas y
subsistemas.
Fortalezas
No se necesita un sistema de
referencia. Permite considerar
explícitamente la rentabilidad de
las medidas de seguridad.
Mantiene, al menos, el
nivel de seguridad
existente y tiende a
mejorar el nivel de
seguridad.
No se necesita ningún
sistema de referencia; se
da un objetivo de
seguridad independiente.
Debilidades
La asignación de
controles/medidas de seguridad a
los peligros no es sencilla y es
necesario seguir trabajando para
comprender su relación.
Necesario sistema de
No se utiliza ampliamente;
referencia con datos de
supuestos arbitrarios para
experiencia; no se ha
la asignación de objetivos
aclarado la compensación de riesgo a subsistemas
mutua de subsistemas más (participación en el riesgo
y menos arriesgados.
global del sistema).
En algunos países, el enfoque de
asignar un valor monetario a las
muertes o lesiones evitadas no es
aceptable.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 61 -
UNE-EN 50126-2:2018
A.2 ALARP (Tan bajo como sea razonablemente práctico)
A.2.1 Generalidades
ALARP significa "tan bajo como sea razonablemente práctico" y se refiere al deber legal de reducir los
riesgos. El principio ALARP surgió originalmente como un requisito legal en el Reino Unido para
reducir los riesgos derivados de las actividades laborales "en la medida en que sea razonablemente
posible", a veces abreviado como SFAIRP (So Far As Is Reasonably Practicable). Impone una obligación
relativa, estableciendo que el responsable del servicio ferroviario debería aplicar cualquier medida de
seguridad que reduzca el riesgo ALARP (a un nivel tan bajo como sea razonablemente práctico). La
determinación de si un control en particular es ALARP se basa en una comparación de los costes netos,
teniendo en cuenta cualquier beneficio comercial, con el grado de reducción del riesgo de cualquier
medida de seguridad o requisito de seguridad que se esté considerando.
En realidad, la aplicación de buenas prácticas establecidas, incluidos los códigos formales de buenas
prácticas, puede considerarse a menudo como una demostración adecuada de que se reduce el riesgo
ALARP. Sin embargo, en algunos casos es necesario llevar a cabo un análisis más formal de los costes y
beneficios, por ejemplo, mediante la evaluación cuantificada de los riesgos y el análisis coste-beneficio
(ACB). En la publicación "Taking Safe Decisions" (RSSB, 2008, http://www.rssb.co.uk/) se incluye una
guía clara sobre cómo emitir juicios ALARP y llevar a cabo el análisis coste-beneficio ACB ALARP.
NOTA Un ejemplo de indicación sobre los juicios ALARP y ACB se puede encontrar en la entrada de la bibliografía relativa a
"Tomar decisiones seguras" (en inglés, taking safe decisions).
Los puntos importantes a tener en cuenta son:
• El principio ALARP considera el cambio en un riesgo y el costo neto de una medida de control. Por
lo tanto, el riesgo que se está considerando podría estar relacionado con una serie de peligros que
afectan a una serie de personas en cierta medida. Por lo tanto, el principio ALARP utiliza
estimaciones colectivas de riesgo y se aplica a las medidas de control;
• El principio ALARP no tiene en cuenta los niveles de riesgo absolutos ni consideraciones sobre la
tolerabilidad del riesgo. Se basa únicamente en una comparación de los costes de una medida con la
reducción del riesgo que logra;
• El principio ALARP es el principal criterio para establecer si se requiere o no una medida de
seguridad. Sin embargo, existen criterios alternativos que pueden considerarse útiles para apoyar
los juicios. Dichos criterios son:
– El nivel residual de riesgo en un ferrocarril, que puede utilizarse como punto de referencia de la
aceptabilidad de un nivel absoluto de riesgo calculado;
– La totalidad del riesgo de muerte al que está expuesta una determinada categoría de personas.
Esto puede establecerlo el regulador - y es poco probable que sea relevante cuando todas las
medidas ALARP se hayan aplicado en un proyecto ferroviario.
A.2.2 Tolerancia y ALARP
Un riesgo podría considerarse tolerable, pero si existen medidas razonablemente practicables que
pueden adoptarse para lograr una mayor reducción del riesgo, no puede considerarse ALARP hasta
que se hayan adoptado dichas medidas.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 62 -
El principio ALARP no se aplica generalmente a riesgos que son comparables a aquellos que la gente
considera insignificantes o triviales en su vida diaria, típicamente riesgos de actividades que son
inherentemente poco peligrosas o de actividades peligrosas que pueden ser, y son, fácilmente
controladas para producir riesgos muy bajos. En tales casos, sería desproporcionado tratar de reducir
aún más el riesgo.
Es concebible que un riesgo pueda ser tanto ALARP como intolerable, es decir, incluso cuando se ha
hecho todo lo razonablemente posible, el riesgo residual permanece en un nivel intolerable. En tal
caso, no debería permitirse la actividad responsable de generar dicho riesgo.
A.3 Principio GAME (Globalmente al menos equivalente)
A.3.1 Principio
El enfoque GAME es legalmente obligatorio en Francia. Otros países también utilizan partes de la
aplicación descrita.
El principio es:
• cualquier sistema/subsistema de transporte público guiado nuevo; o
• cualquier modificación de un sistema/subsistema existente
debería ser globalmente tan segura o más segura que la existente aceptada como sistema de
referencia.
Para alcanzar este nivel, el sistema o la modificación debería diseñarse y llevarse a cabo de manera
que el nivel global de seguridad de los usuarios, del personal de explotación y de terceros3) sea al
menos equivalente al nivel de seguridad de los sistemas existentes que prestan servicios similares.
Esto tiene en cuenta la experiencia del pasado y requiere que el comportamiento en materia de
seguridad del sistema proyectado no sea peor que el de sistemas similares (de referencia), mediante la
frase "al menos". No considera la seguridad en un nivel de riesgo particular, sino en el nivel de
seguridad global del sistema/subsistema estudiado, utilizando el requisito "global". El proveedor del
sistema de transporte es libre de asignar partes de riesgo a subsistemas dentro del sistema o entre
riesgos "similares" y aplicar el enfoque pertinente, es decir, cualitativo o cuantitativo (dependiendo del
tipo de fallo que lleve al peligro). Por ejemplo, un análisis cuantitativo podría ser útil para evaluar la
tasa de fallos de un elemento de equipo, pero podría no ser pertinente para un peligro debido a un
factor humano.
En la aplicación del principio GAME deberían tenerse en cuenta tanto los riesgos colectivos como los
individuales.
La guía "Principe GAME (Globalement Au Moins Équivalent) Méthodologie de démonstration" se
encuentra disponible en el sitio web del STRMTG (Service Technique des Remontées Mécaniques et des
Transports Guidés) http://www.strmtg.equipement.gouv.fr
3) Terceros pueden ser residentes, peatones, trabajadores/empleados externos o personal de emergencia (policías,
bomberos, personal médico...) que puedan estar presentes en circunstancias particulares.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 63 -
UNE-EN 50126-2:2018
A.3.2 Aplicación del principio GAME
A.3.2.1 Generalidades
El principio GAME puede utilizarse de diferentes maneras para diferentes propósitos. Este apartado
explica las diferentes maneras en que el principio GAME puede ser un enfoque eficaz y eficiente para
evaluar la aceptabilidad del riesgo asociado con un determinado sistema.
A.3.2.2 Principios básicos
Existen algunos prerrequisitos importantes para aplicar el principio GAME:
• el sistema en consideración puede compararse con un sistema de referencia equivalente o similar
(con respecto a la aplicación);
• se puede definir un límite claro del sistema tanto para los sistemas nuevos como para los de
referencia;
• las propiedades relevantes para los riesgos considerados son conocidas tanto para el sistema nuevo
como para el sistema de referencia;
• cualquier diferencia en las propiedades ha de compensarse en el establecimiento de objetivos de
riesgo o en la demostración del cumplimiento;
• la prueba de que el sistema de referencia se considera aceptable desde el punto de vista de la
seguridad (de lo contrario, este sistema no puede tomarse como referencia).
La demostración del principio GAME debería hacerse a través de:
• un enfoque sistemático de la seguridad que permita la identificación de los peligros para el sistema
en su conjunto y la definición de los requisitos pertinentes;
• la prueba de que cada peligro se evita utilizando medidas de protección o se atenúan mediante
medidas de mitigación;
• la prueba de que cada medida de protección y mitigación es eficaz en relación con el peligro
correspondiente;
• un proceso de gestión de la seguridad apropiado (basado en normas reconocidas y adecuadas)
destinado a registrar, gestionar y controlar los peligros (y sus correspondientes medidas de
protección o atenuación) y los requisitos pertinentes.
A.3.2.3 Aplicación del principio GAME para construir un argumento cualitativo de seguridad
En algunos casos se puede utilizar un argumento cualitativo para demostrar el cumplimiento utilizando
el principio GAME. Si se utiliza el principio GAME de esta manera, es muy importante establecer y
demostrar que las condiciones de aplicación de ambos sistemas son idénticas. Cualquier diferencia en
las condiciones de aplicación ha de examinarse para determinar si existe la posibilidad de:
• introducir nuevos peligros;
• afectar a la probabilidad de que se produzcan peligros conocidos;
• ampliar las consecuencias de los peligros conocidos.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 64 -
A.3.2.4 Aplicación del principio GAME utilizando objetivos cuantitativos de riesgo
Otra forma de aplicar el principio GAME es mediante el uso de objetivos cuantitativos de riesgo. Esto
puede hacerse en cualquier nivel de integración en el sistema ferroviario (tanto para un sistema
ferroviario completo como para un subsistema). La referencia será siempre la contribución del sistema
al riesgo a nivel de todo el sistema ferroviario.
A.4 Mortalidad Mínima Endógena, MEM
MEM es un método para obtener valores absolutos para la aceptación de riesgos basados en la tasa de
mortalidad natural de seres humanos de edad específica.
MEM es un enfoque con supuestos predefinidos y se basa en el trabajo de A. Kuhlmann en Alemania en
1981. En los siguientes párrafos se ofrece un resumen de dicho documento.
El criterio MEM asigna el mismo riesgo a un individuo, independientemente de cualquier sistema
técnico. La asignación del mismo riesgo a un individuo ha de justificarse si se utiliza el criterio MEM.
El método MEM incorpora la tasa de mortalidad natural más baja y la utiliza para asegurar que el
riesgo técnico adicional total para un individuo no exceda un valor equivalente a este riesgo natural. La
tasa de mortalidad natural se centra sólo en las causas naturales de muerte sin influencia de ningún
tipo de accidente o de malformaciones de nacimiento.
En el rango entre 5 y 15 años de edad para los seres humanos, la tasa de mortalidad natural (Rm) en
los estados industrializados alcanza un mínimo para los individuos humanos:
Rm = 2  10-4 muertes / (persona  año)
El método MEM establece que la tasa de mortalidad por peligro general adicional causada por los
sistemas técnicos (Rt) no debería exceder este límite:
Rt ≤ Rm
y cada sistema individual no debería aportar más del 5 % porque cada individuo está en peligro por n
sistemas técnicos diferentes en paralelo; el principio MEM supone:
n ≤ 20
Esto significa que un solo sistema técnico no debería conducir a un riesgo de muerte (R) de una sola
persona con una tasa de:
R ≤ 10-5 muerte / (persona  año)
Debido a que no se aceptan accidentes con un elevado número de víctimas mortales, el principio MEM
introduce un factor de "aversión diferencial al riesgo" (DRA, Differential Risk Aversion), que da como
resultado la siguiente curva.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 65 -
UNE-EN 50126-2:2018
Figura A.1 – Aversión diferencial al riesgo
Para el cálculo en MEM, la relación entre muertes, lesiones graves y lesiones leves viene dada por:
Una víctima mortal = 10 lesiones graves = 100 lesiones leves (lesiones graves ⇔ personas que se
convierten en discapacitadas)
EJEMPLO
Un accidente con 2 lesiones graves y 40 lesiones leves corresponderá a 2/10+40/100 = 0,6 víctimas
mortales equivalentes.
El principio no define qué es un "sistema". Dado que el criterio se basa en las "muertes", es
especialmente aplicable a los sistemas que afectan directamente a la salud humana. Puede
interpretarse que no más de 20 sistemas imponen riesgos mortales a un grupo específico de personas
al mismo tiempo. Por tanto, este método puede utilizarse para evaluar estos peligros por separado, ya
que no se permite que ninguno de ellos aumente significativamente la tasa de mortalidad.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 66 -
Anexo B (Informativo)
Utilización de estadísticas de fallos y accidentes
para obtener una tasa de peligro tolerable (THR)
Las tasas de peligro tolerables (THR) no pueden calcularse a partir de las estadísticas de accidentes a
menos que se disponga de estadísticas y modelos rigurosamente recopilados. Sin embargo, incluso si
tales modelos no existen, el uso de tales estadísticas, cuando están presentes, puede ser parte del
proceso de llegar a un juicio informado del nivel en el que se deben establecer las tasas de peligro
tolerables (THR).
Las estadísticas y los datos de la red ferroviaria pueden utilizarse para determinar las tasas de peligro
tolerables sensibles en algunas circunstancias. Esto puede realizarse, como es la práctica actual en el
Reino Unido, mediante:
• la revisión de la frecuencia de ocurrencia de peligros funcionales/técnicos en la red ferroviaria;
• la utilización de esta información e información sobre el número de unidades instaladas en un
entorno ferroviario determinado para calcular las tasas medias de fallos peligrosos por unidad en
esa zona determinada (por ejemplo, la red ferroviaria nacional, o parte de ella);
• la revisión de las tasas de accidentes e incidentes para estimar el riesgo residual en la red de tales
peligros funcionales y, por implicación, si las tasas actuales de peligros funcionales son aceptables.
La tasa de fallos peligrosos para un sistema ferroviario determinado por hora de funcionamiento
podría estimarse mediante:
λhora por unidad = Naño /(horasaño* número de unidades).
con Naño como el número de fallos peligrosos por año.
Por ejemplo, si suponemos que:
• un ferrocarril nacional tiene 60 000 circuitos de vía en su red;
• por término medio, 6 de ellos fallan al indicar su ocupación, es decir, de manera que no indican
cuándo están ocupados, en un año determinado;
• cada circuito de vía estará operativo durante 19 horas al día, 365 días al año (6 935 horas de
funcionamiento al año).
Entonces:
λhora por unidad = 6/(6 935*60 000) = 1,4E-08 fallos por hora.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 67 -
UNE-EN 50126-2:2018
Sin embargo, para entender si esta tasa de peligro funcional es aceptable o no para su adopción como
tasa de peligro tolerable (THR), es necesario comprender si el riesgo residual asociado con ella es
aceptable. Esto se basaría en una revisión de las estadísticas de accidentes a lo largo de varios años
para determinar si un peligro de este tipo ha provocado algún accidente. Si durante un período
razonable el peligro no hubiera dado lugar a accidentes, podría llegarse a la conclusión de que la tasa
de fallo era aceptable, dadas otras medidas de control de riesgos y factores circunstanciales. Si se han
producido accidentes, el análisis del peligro y de otras medidas de protección relacionadas con su
ocurrencia debería formar parte del dictamen.
Este cálculo no necesita incluir un tiempo medio de reparación, si se supone que cada fallo se
detectaría cuando el siguiente tren llegue al circuito de vía. Por lo tanto, podría suponerse que, por
cada fallo, existe una posibilidad similar de accidente.
Si se va a utilizar la tasa de peligro tolerable (THR) para un sistema ferroviario nuevo o modificado,
debería realizarse un análisis de impacto en relación con los contextos funcionales y del entorno entre
la red existente y el sistema ferroviario nuevo o modificado para comprobar la aplicabilidad de la tasa
de peligro tolerable (THR) determinada para el sistema cuyo fallo podría provocar el peligro y el
accidente resultante.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 68 -
Anexo C (Informativo)
Directrices para la asignación de un nivel de integridad de la seguridad
(SIL)
Este anexo proporciona directrices sobre la asignación de niveles de integridad de la seguridad (SIL)
con una lista de preguntas típicas sobre el uso y mal uso de los criterios de asignación de niveles de
integridad de la seguridad (SIL).
1.
¿Es correcto decir que el nivel de integridad de la seguridad (SIL) está relacionado con la parte
sistemática de la integridad de la seguridad y la tasa de fallo funcional tolerable (TFFR) con la
parte aleatoria?
No es correcto. Si bien es correcto afirmar que la tasa de fallo funcional tolerable (TFFR) está
relacionada principalmente con la parte aleatoria de la integridad de la seguridad, el nivel de
integridad de la seguridad (SIL) asociado proporciona un vínculo con la parte sistemática. El nivel
de integridad de la seguridad (SIL) define un conjunto de medidas cualitativas. Muchas de ellas
tienen por objeto proteger contra fallos sistemáticos, pero algunas son defensas contra fallos
aleatorios (por ejemplo, arquitecturas específicas o el principio de fallo único).
2.
Para una sola función, ¿se deben aplicar las medidas cualitativas del nivel de integridad de la
seguridad (SIL) también a las subfunciones en la descomposición funcional?
Parte de los requisitos expresados para la función se aplican en todo el desarrollo, por lo que
también son aplicables a sus componentes (por ejemplo, medidas de calidad y seguridad).
Algunos requisitos, como las restricciones de seguridad arquitectónicas, sólo son aplicables al
nivel de la función.
3.
¿Pueden dos funciones, relacionadas con peligros diferentes, compartir las mismas medidas
cualitativas del nivel de integridad de la seguridad (SIL)? Por ejemplo, las mismas características
de diseño, la misma detección dinámica de fallos, etc.
Sí que pueden. Las funciones relacionadas con la seguridad dentro de un sistema se implementan
a través de un proceso de desarrollo y de subsistemas. El proceso cumple con las medidas de
calidad y seguridad, y el subsistema implementa las medidas arquitectónicas - medidas definidas
dentro del conjunto de las respectivas medidas cualitativas SIL.
Tanto el proceso como el subsistema serán comunes a varias funciones diferentes.
4.
¿Qué sucede si un subsistema implementa una serie de funciones relacionadas con diferentes
peligros, cada uno de los cuales podría requerir un nivel de integridad de la seguridad (SIL)
diferente?
En este caso, son posibles dos opciones alternativas:
– que cada función cumpla con las más altas exigencias del nivel de integridad de la seguridad
(SIL);
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 69 -
UNE-EN 50126-2:2018
– si se puede demostrar la no intrusión mutua, que cada función pueda satisfacer su propio nivel
de integridad de la seguridad (SIL) requerido.
5.
¿Se puede repartir el nivel de integridad de la seguridad (SIL) de una función entre sus
subfunciones?
Esto sólo es posible para la TFFR (tasa de fallo funcional tolerable) en condiciones de
independencia. Cuando una función se divide en varias subfunciones, esta distribución no debería
reflejarse en una distribución del propio nivel de integridad de la seguridad (SIL), ya que el SIL
solo se asigna una vez durante la distribución. Luego, durante su diseño e implementación, si
existen mecanismos para prevenir que el fallo de un componente cause que la función pase a un
estado no seguro, la asignación puede rehacerse y llegar a la conclusión de que podría ser
suficiente un nivel de integridad de la seguridad (SIL) menos estricto.
6.
¿Cómo se puede asignar un nivel de integridad de la seguridad (SIL) para una parte electrónica de
una función compleja realizada con varias tecnologías?
En este caso, no se puede dar una regla general.
Se ha de considerar, por ejemplo, un sistema de bloqueo de puertas. Para mantener las puertas
cerradas, la seguridad está garantizada tanto por una cerradura mecánica como por un control
electrónico. La parte mecánica se construirá de acuerdo con un Código de buenas prácticas, por lo
que los peligros se tratan suficientemente de acuerdo con el enfoque del Código de buenas
prácticas. Sin embargo, el nivel de integridad de la seguridad (SIL) para el control electrónico
también podría ser mayor si el control es necesario para otras funciones relacionadas con la
seguridad.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 70 -
Anexo D (Informativo)
Métodos de distribución de los objetivos de seguridad
D.1 Análisis del sistema y de los métodos
El objetivo de la distribución de los requisitos de seguridad del sistema es "descomponer" los objetivos
de integridad de la seguridad determinados a nivel de un sistema en los niveles inferiores, es decir, en
las subfunciones y subsistemas y, cuando sea necesario, entre los distintos agentes (por ejemplo,
proveedores ferroviarios y subcontratistas ferroviarios).
El primer paso del método de distribución consiste en analizar las diferentes funciones que
contribuyen a los peligros identificados y comprobar si son independientes entre sí.
La independencia implica aspectos tanto aleatorios como sistemáticos de los fallos.
Al considerar los mecanismos de detección y anulación de fallos, los modelos deberían justificar la
detección segura, el tiempo de anulación y los supuestos relacionados con la cobertura de los medios
de detección.
La distribución se puede realizar de tres maneras:
– cualitativamente;
– cuantitativamente;
– mezclando datos cualitativos y cuantitativos.
D.2 Ejemplo de método cualitativo de distribución
D.2.1 Generalidades
Este apartado proporciona un ejemplo de distribución cualitativa mediante un árbol de fallos en caso
de una función con medidas de protección.
La tasa de peligro tolerable THR (A) asociada al peligro (A) se distribuye entre los sistemas técnicos
teniendo en cuenta las posibles consecuencias del peligro y las medidas de protección existentes
(reduciendo la gravedad y/o la frecuencia del accidente).
A continuación, la tasa de peligro tolerable (THR) distribuida (A) puede distribuirse entre las
funciones de los niveles inferiores (B y C) en forma de tasa de fallo funcional tolerable (TFFR).
Cuando se identifica un nivel como el nivel más bajo en el que se puede demostrar la independencia,
entonces se puede asignar un nivel de integridad de la seguridad (SIL). Este nivel de integridad de la
seguridad (SIL) se aplicará a continuación a los niveles inferiores y no se puede distribuir.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 71 -
UNE-EN 50126-2:2018
Figura D.1 – Ejemplo de método cualitativo de distribución
Si una función (por ejemplo, C en nuestro ejemplo) es una medida de protección, es necesario
comprobar si la reducción del riesgo de la medida de protección se producirá en todos los casos, o si
depende de un contexto específico. Esto puede evaluarse a través de un método cualitativo,
posiblemente guiado por un conjunto semicuantitativo de directrices (véase D.2.2). Se podría asignar
un nivel de integridad de la seguridad (SIL) en caso de que se asocie un valor cuantitativo a la
eficiencia de la medida de protección.
D.2.2 Ejemplo de método cualitativo para la eficacia de las medidas de protección
Por lo general, este método se utiliza mejor para tratar eventos cuyas consecuencias conducen a
riesgos bajos (donde, por tanto, es razonable limitar el esfuerzo en el estudio).
El método cualitativo se concentrará generalmente en cuántos fallos son necesarios para que se
produzca el incidente y en el juicio de los expertos (basado en un resultado de la experiencia no
siempre basado en las estadísticas).
Es importante señalar que para que el juicio de un experto sea válido, deberían seguirse los siguientes
pasos:
• El "juicio" no ha de realizarlo una sola persona, sino:
○ un grupo de expertos (argumento colectivo);
○ y/o con argumentos documentados (por ejemplo, de un proveedor ferroviario).
• El "juicio" utiliza en la medida de lo posible los resultados de la experiencia (sin embargo, con la
debida precaución => ¿son los datos aplicables para ese uso?)
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 72 -
Un ejemplo de método cualitativo puede ser el siguiente, identificando con la debida justificación los
valores de rango de eficiencia E:
Tabla D.1 – Eficiencia basada en los fallos del componente
Juicio de expertos sobre los fallos del componente (E F)
Valor
El componente nunca ha fallado en la vida útil de los sistemas existentes que utilizan este
componente
E IF
Se han producido algunos fallos durante la vida útil de los sistemas existentes que utilizaban este
componente (menos de uno por sistema)
E IIF
Se ha producido al menos un fallo durante la vida útil de cada uno de los sistemas que utilizan este
componente
E III
F
Al menos un fallo al año en los sistemas (menos de uno por sistema)
E IV
F
Se ha producido al menos un fallo cada año en cada sistema
E FV
NOTA Se aconseja no utilizar EF = 1, ya que es un valor "imposible" para la mayoría de los componentes. En la mayoría de los
casos, los únicos componentes que pueden alcanzar este valor son los componentes mecánicos que se sustituyen
mediante un mantenimiento preventivo basado en criterios (por tanto, nunca se produce ningún fallo, ya que el
componente se cambia antes de que pueda fallar, por ejemplo, los bogies).
Tabla D.2 – Eficiencia basada en el conocimiento del componente
Juicio experto sobre el conocimiento del componente (EK)
Valor
El componente es ampliamente utilizado en la empresa
E IK
El componente se utiliza en la empresa, pero no en aplicaciones importantes (altas expectativas de
seguridad / fiabilidad)
E IIK
El componente no se utiliza en la empresa, sino que sustituye a un componente utilizado en la
empresa
E III
K
El componente no se utiliza en la empresa y no se conoce
E IV
K
Tabla D.3 – Eficiencia basada en el uso del componente
Juicio de expertos sobre el uso del componente / LRU (EU)
El componente ya se utiliza en las mismas aplicaciones
Valor
E IU
El componente no se utiliza en las mismas aplicaciones, sino en aplicaciones similares (por
ejemplo, no en la misma función, no en aplicaciones ferroviarias sino en aviones) => restricciones
similares en el componente
E II
U
El componente no se utiliza en el ferrocarril o en aplicaciones similares (por ejemplo, las
restricciones son demasiado diferentes)
E III
U
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 73 -
UNE-EN 50126-2:2018
Tabla D.4 – Eficiencia basada en el mantenimiento del componente
Juicio de expertos sobre el mantenimiento (EM)
Valor
El componente ha de someterse a ensayos diariamente y el sistema no está autorizado a utilizarse
antes de la reparación
E IM
El componente ha de someterse a ensayo en línea, pero la reparación se puede posponer a una
semana (máximo)
E IIM
El componente ha de someterse a ensayo, pero la reparación puede posponerse un mes (máximo)
E III
M
El componente ha de someterse a ensayo, pero la reparación puede posponerse 6 meses (máximo)
E IV
M
El componente ha de someterse a ensayo, pero la reparación se puede posponer un año (máximo)
V
EM
El componente ha de someterse a ensayo, pero la reparación puede posponerse hasta la mitad de
la vida útil del sistema (máximo)
VI
EM
El componente no se somete a ensayo, no es necesario repararlo durante la vida útil del sistema
VII
EM
Estos diferentes criterios se combinarán para proporcionar la "eficiencia" de un componente. Esta
combinación se hace generalmente a través de una multiplicación:
E = E F  EK  E U  E M
D.3 Ejemplo de método cuantitativo de distribución
D.3.1 Introducción
Un método cuantitativo permite una distribución más precisa de un objetivo de seguridad entre los
subniveles. Sin embargo, depende de:
– la adecuación de las hipótesis tomadas durante el cálculo, y
– la experiencia adquirida en sistemas de referencia similares ya en servicio (para validar la
viabilidad y adecuación de un objetivo distribuido).
La verificación cuantitativa puede realizarse a través de varios métodos. Sin embargo, es importante
no olvidar el impacto del mantenimiento, ya que cuanto más bajo es el mantenimiento, más fiable y
seguro ha de ser un elemento para mantener el mismo nivel de disponibilidad general.
Antes de cuantificar, se deberían realizar los siguientes pasos para asegurar que los resultados sean
válidos:
• comprobar que las hipótesis tomadas para cada componente son válidas también para el sistema en
el que está integrado el componente;
• comprobar la conformidad del entorno para todos los componentes (temperatura, CEM);
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 74 -
• comprobar que el entorno operativo considerado para cada componente es compatible con el
entorno operativo considerado para el sistema en su conjunto (tiempo de uso, tiempo en tensión,
número de solicitaciones);
• comprobar que las condiciones de funcionamiento son realmente aplicables y se aplicarán
(referencia a la documentación de operación/mantenimiento correspondiente).
El modelo a considerar para la combinación de dos fallos funcionales independientes que conducen a
un peligro se presenta a continuación.
Después de que haya aparecido una avería en un elemento, al menos dos cosas suceden para que el
elemento vuelva a funcionar:
• Se detecta y anula la avería (esto significa que debe introducirse un estado seguro).
• Se repara y restaura el elemento.
Con el tiempo de reparación y restauración se entiende el tiempo logístico para la reparación después
de la detección, el tiempo de reparación real (localización de la avería, reparación, cambio,
comprobación) y el tiempo para restaurar el equipo para ponerlo de nuevo en funcionamiento.
Mientras que en un contexto de fiabilidad normalmente se ignora el tiempo de detección, este tiempo
es importante en el contexto de la seguridad.
Figura D.2 – Interpretación de los tiempos de avería y reparación
En la mayoría de los casos, la anulación ocurre durante la restauración del elemento. En algunos casos,
sin embargo, se puede imponer un estado seguro sin restauración. En este caso, estado seguro significa
que "el nivel de seguridad después de la anulación es al menos equivalente al nivel de seguridad antes
de que se produjera el fallo".
NOTA 1 Para la mayoría de los componentes (especialmente aquellos con requisitos de seguridad bajos), no existe
anulación, por tanto SDT = MDT (no existe operación degradada segura, la operación degradada es no segura, o
menos segura que antes del fallo).
NOTA 2 En algunos casos, el tiempo de anulación = 0 ya que el fallo de un elemento hace que el sistema sea más seguro (por
ejemplo, la ausencia de energía implica frenar). Sin embargo, que el tren se encuentre parado no se considerará un
estado seguro durante mucho tiempo, por ejemplo, cuando los pasajeros bajen del tren).
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 75 -
UNE-EN 50126-2:2018
Los apartados siguientes ofrecen ejemplos de combinación Y de dos contribuciones independientes
para los siguientes casos:
• funciones con mecanismos independientes de detección y anulación de fallos;
• medida de protección funcional e independiente, con mecanismo de detección y anulación de fallos
asegurado por la medida de protección.
En caso de que se identifiquen fallos de causa común, la contribución correspondiente se añade a la
cuantificación resultante.
En todos los casos, cuando se identifica un nivel como el nivel más bajo en el que se puede demostrar
la independencia, se puede asignar un SIL (nivel de integridad de la seguridad). Este nivel de
integridad de la seguridad (SIL) se aplicará a continuación a los niveles inferiores y no se puede
distribuir.
D.3.2 Funciones con mecanismos independientes de detección y anulación de fallos
En el modelo mostrado en la figura D.3, las causas de peligro (X) e (Y) se originan por el fallo de las
funciones (X) e (Y) respectivamente. Cuando se produce un fallo no seguro en solo una de estas
funciones, la otra función sigue funcionando y el sistema sigue siendo seguro. El sistema se vuelve no
seguro cuando ambas funciones fallan.
Los mecanismos de detección y anulación de fallos asociados a las funciones (X) e (Y) se suponen
libres de fallos de causa común. Los tiempos SDTX y SDTY para detectar y anular los fallos de las
funciones (X) e (Y) son parámetros significativos para lograr el funcionamiento de seguridad
requerido. Deberían mantenerse tan bajos como sea posible mediante su diseño y otras medidas.
En caso de funciones reparables, los tiempos de reparación relacionados también son parámetros
significativos.
Figura D.3 – Combinación de dos funciones con mecanismo independiente de detección y
anulación de fallos
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 76 -
Este modelo parece una estructura redundante con dos elementos diferentes e independientes en
paralelo y ningún elemento en serie considerado para los fallos en modo común.
El siguiente modelo considera:
– las tasas de peligro tolerables THRX y THRY de las causas de peligro (X) e (Y), desencadenadas por
los fallos de las funciones (X) e (Y) respectivamente;
– las tasas de caída segura SDRX y SDRY vinculadas a las funciones (X) e (Y), con SDRi ≈ 1/SDTi y SDTi
= tiempo medio de detección y anulación de fallos de la función (i);
– las tasas de reparación (incluido el funcionamiento degradado seguro, la reparación y la
restauración) μX y μY de las funciones (X) e (Y).
Suponiendo una reparación instantánea comparada con los tiempos de detección y anulación de los
fallos de las funciones (X) e (Y), la tasa de peligro tolerable (THR) relacionada con el peligro (A) puede
reducirse a la fórmula (1).
THR A  THR X  THR Y 
SDR X + SDR Y
SDR X × SDR Y
(1)
Suponiendo una detección y anulación instantáneas comparadas con los tiempos de reparación de los
fallos de las funciones (X) e (Y), la tasa de peligro tolerable (THR) relacionada con el peligro (A) puede
reducirse a la fórmula (2).
THR A  THR X  THR Y 
µX +µY
µY ×µX
(2)
NOTA Esta fórmula se estipula también en las Normas IEC 61025 e IEC 61165.
En los siguientes párrafos, se considera el segundo caso solamente, con la fórmula (2).
La vida útil del sistema o el intervalo de tiempo de mantenimiento preventivo de las funciones (X) e
(Y) pueden limitar el valor del término (μX+μY)/μXμY, con potencialidad para relajar las tasas de peligro
tolerable THRX o THRY o ambas tasas de peligro tolerable (THR) de las causas del peligro.
Por lo que se refiere a los requisitos de integridad de la seguridad (SILX y SILY) que han de asignarse a
las funciones (X) e (Y) para el control de fallos sistemáticos, como se muestra en la figura D.4, la tabla
TFFR/SIL solo se utiliza cuando estas funciones no pueden seguir desarrollándose hasta convertirse
en subfunciones independientes a través de una puerta Y. La asignación de un nivel de integridad de la
seguridad (SIL) a las funciones (X) e (Y) debería realizarse en esta fase con la distribución de THR A a
THRX y THRY según las limitaciones de la vida útil del sistema o del intervalo de tiempo de
mantenimiento preventivo.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 77 -
UNE-EN 50126-2:2018
Figura D.4 – Asignación de los requisitos de integridad de la seguridad
D.3.3 Función y medida de protección independiente que actúa como mecanismo de
detección y anulación de fallos
Este caso se muestra en la figura D.5, donde la Causa de Peligro (F) se origina por el fallo de la función
(F).
Cuando se produce un fallo no seguro en la función (F), el objetivo de la medida de seguridad (G) es
detectar y anular dicho fallo no seguro, es decir, proteger contra cualquier funcionamiento no seguro
de la función (F).
Figura D.5 – Combinación de función y medida independiente que actúa como mecanismo de
detección y anulación de fallos
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 78 -
Cuando se produce un fallo solo en la medida de seguridad (G), la estructura permanece en un estado
seguro aunque degradada. Sin embargo, cualquier fallo detectado en la medida de seguridad (G)
también podría anularse, de modo que toda la estructura alcanzaría y permanecería en un estado
seguro incluso si se produjera un fallo no seguro de funcionamiento (F). La estructura no es segura si
fallan tanto la función (F) como la medida de seguridad (G).
El siguiente modelo considera:
– la tasa de peligro tolerable THRF de la causa del peligro (F);
– la tasa de peligro tolerable THRG ligada al fallo de la medida de seguridad (G);
– las tasas de caída segura SDRP y SDRG asociadas a la medida de seguridad (G), para proteger contra
la causa del peligro (F) y el fallo de la medida (G), con SDRP ≈ 1/SDTP y SDRG ≈ 1/SDTG.
Siempre que se cumpla la restricción THRi << SDRi, la tasa de peligro tolerable (THR) relacionada con
el peligro (A) puede reducirse a la fórmula (3), que proporciona una expresión aproximada del valor
asintótico de THRA.
THR A = THR F × THR G ×
SDR P + SDR G
THR F × SDR G + THR G × SDR P
(3)
Suponiendo que SDRG = SDRP, es decir, que los tiempos de detección y anulación son iguales para la
causa del peligro y el fallo de la medida de protección, conduce a:
THR A =
2 × THR F × THR G
THR F + THR G
(4)
Por lo que se refiere a los requisitos de integridad de la seguridad (SILG) que han de asignarse a la
función (G) para el control de fallos sistemáticos, la tabla TFFR/SIL solo se utiliza cuando esta función
(G) no puede seguir desarrollándose hasta convertirse en subfunciones independientes mediante
puertas Y.
D.3.4 Distribución de un objetivo de probabilidad de seguridad
Cuando se trata de probabilidades, se aplican las siguientes fórmulas para la distribución:
• Para una puerta O: Σ probabilidades distribuidas ≤ probabilidad total a distribuir
• Para una puerta Y: Π probabilidades distribuidas ≤ probabilidad total a distribuir
• La distribución a través de una puerta Y de probabilidades requiere suposiciones sobre los tiempos
de caída seguros SDT.
○ Las funciones B y C son independientes.
○ La probabilidad de una PUERTA Y entre B y C sería PB x PC, que en el caso de que la ley de
probabilidad utilizada sea una ley exponencial sería:
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 79 -
PB × PC  (1  e
 λ B ×SDTB
)  (1  e
 λ C ×SDTC
UNE-EN 50126-2:2018
)  λ B × SDTB × λ C × SDTC
(solo válido si λB  SDTB << 1 y λC  SDTC << 1)
○ Por tanto, al distribuir λB y λC, debería hacerse una suposición conservadora sobre los valores de
SDTB y SDTC.
D.3.5 Distribución de un objetivo de seguridad "por hora"
La distribución a través de una puerta O se realiza asegurando que la suma de la tasa de fallos
distribuida permanezca inferior o igual al objetivo.
Es importante garantizar que se distribuya la máxima tasa de fallo equivalente.
La probabilidad máxima y la tasa de fallo equivalente se alcanzan en el múltiplo común más pequeño
de los tiempos de caída seguros (es decir, cuando la probabilidad de fallo es mayor para cada
componente individual).
Un ejemplo de distribución podría ser el siguiente, como se muestra en la figura D.6.
• C tiene un tiempo de caída seguro de 12 h, es decir, SDTC = 12 h.
• B tiene un tiempo de caída seguro de 15 años (suponiendo 15 años con 300 días al año de uso),
SDTB = 24  300  15 = 108 000 h
Si aplicamos este método a un caso en el que el nivel superior de la tasa de peligro tolerable (THR) es
10-9/h, una posible distribución podría ser la siguiente:
10-9/h = λC  λB  (108 000 h + 12 h) → λC  λB = 9,26 · 10-15/h2
Se podrían hacer por tanto las siguientes distribuciones:
λB = 9,26  10-8/h y λC = 10-7/h
Figura D.6 – Ejemplo de distribución cuantificada
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 80 -
Anexo E (Informativo)
Errores comunes en la cuantificación
E.1 Usos erróneos comunes
A continuación se presentan algunos usos erróneos comunes en los métodos de cuantificación que
pueden conducir a resultados erróneos:
E.2 Mezcla de tasas de fallo con probabilidades
Este error a menudo proviene del uso de componentes de "tasas de fallo constantes" y de las leyes de
probabilidad asociadas. Es normalmente el caso cuando se utiliza la ley exponencial que proporciona
esta simplificación de la "tasa de fallo constante".
El cálculo de una tasa de fallo para un sistema utilizando solo las tasas de fallo de los componentes
(por tanto, sin utilizar ningún tiempo de caída seguro) generalmente sobreestimará la seguridad del
sistema:
Figura E.1
NOTA En el caso del Análisis en Árbol de Fallos (AAF) que se muestra en la figura E.1, "ensayo periódico 1e-6 10 0" significa:
•
La ley de probabilidad utilizada es el ensayo periódico (basada en leyes exponenciales, pero con ensayos
periódicos de los componentes).
•
La tasa de fallo del componente es 10-6/h.
•
El periodo de ensayo es de 10 h (cada 10 h, el componente se somete a ensayo, y se repara si es necesario - o se
prohíbe el uso del sistema hasta que se logre la restauración).
•
El primer ensayo se realiza en el momento de la entrega de la instalación (o en el momento de su primera
utilización).
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 81 -
UNE-EN 50126-2:2018
Utilizando el ejemplo anterior, si simplemente se multiplican las tasas de fallo (10 -7/h  10-6/h), se
obtiene 10-13/h2, y la unidad ya no es correcta (/h  /h = /h), porque no se ha considerado la
contribución al periodo de ensayo.
La fórmula utilizada para las puertas Y en las que se utiliza una multiplicación solo es válida para una
probabilidad (es decir, una tasa de fallo multiplicada por una unidad de tiempo).
E.3 Utilización de fórmulas fuera de su ámbito de aplicación
Un ejemplo de error es el uso de lambda equivalente cuando la tasa de fallo es alta (cercana o superior
a 1/h), y/o cuando el tiempo de caída seguro es muy largo (por ejemplo, el fallo no puede detectarse →
tiempo de caída seguro = vida útil del sistema).
En tales casos, cuando λeq  Teq << 1 no es válido, los resultados serán erróneos (error no despreciable
con respecto a los modelos analíticos, es decir, integral de las funciones de densidad de probabilidades
durante su tiempo de caída seguro).
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 82 -
Anexo F (Informativo)
Técnicas/métodos para el análisis de seguridad
Las siguientes tablas ofrecen una visión general no exhaustiva de las diversas técnicas y métodos
utilizados durante las fases del ciclo de vida. Se pueden encontrar más detalles en las correspondientes
normas IEC.
Tabla F.1 – Técnicas/Métodos para el análisis de seguridad
Técnica/Método
RRA (Rapid Ranking
Analysis)
Identificación de
peligro
Con fines
preliminares
Requisitos de
seguridad/análisis de
peligros
Posible para
–
registrar los
motivos por los que
no se realiza un
análisis más
detallado de los
peligros de baja
clasificación.
–
Parcialmente útil
como elemento de
apoyo
61882: 2001
Útil
Útil para estructuras
paralelas junto a
Análisis por Árbol de
Eventos (ETA)
Útil para
estructuras simples
y paralelas junto a
un Análisis por
árbol de fallos
(AAF) y para un
análisis causal
60812:2006.
Técnicas de análisis
de la fiabilidad de
sistemas.
Procedimiento de
análisis de los
modos de fallo y de
sus efectos (AMFE)
–
–
Útil en ocasiones
62502:2010.
para visualizar
Técnica de análisis
consecuencias de un de la confiabilidad.
fallo en un
Análisis por árbol
(sub)sistema
de eventos (ETA)
–
–
Útil para
estructuras
múltiples, análisis
causal
Rango de peligros
HAZOP (Hazard and Útil
Operational Analysis)
Estudios de peligros
y operatividad
Análisis de los modos
de fallo, efectos y
criticidad
ETA (Event Tree
Analysis)
Análisis por Árbol de
Eventos
AAF
Análisis por árbol de
fallos
Referencia a
norma IEC
Útil para el análisis
preliminar de peligros y
para identificar y
clasificar los peligros
con objeto de realizar
un análisis más
detallado
Análisis rápido de
clasificación;
FMECA (Failure
Mode, Effects and
Criticality Analysis)
Demostración de
seguridad
61025:2010.
Técnicas de análisis
para la fiabilidad
del sistema.
Análisis por árbol
de fallos
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 83 -
Técnica/Método
CCF (Common Cause
Analysis)
Identificación de
peligro
Requisitos de
seguridad/análisis de
peligros
–
–
Complementario y a –
menudo resuelto
con un Análisis de
los modos de fallo y
efectos y criticidad
(FMECA) Necesario
también para
justificar puertas Y
en el Análisis en
Árbol de Averías
–
Especialmente útil para
modelar secuencias de
estados y de fallos
Especialmente útil
para modelar
secuencias de
estados y de fallos
Análisis de Causas
Comunes
Markov
UNE-EN 50126-2:2018
Demostración de
seguridad
RBD
Útil como apoyo a
un Estudios de
Diagrama de bloques peligros y
de la fiabilidad
operatividad
(HAZOP) y Análisis
en Árbol de Fallos
(FTA)
Gráfico de Riesgos
–
Referencia a
norma IEC
61165:2006
61078:2006
Técnica que ha de
calibrarse de acuerdo
con un criterio de
aceptación de riesgos
claramente definido y
aplicarse a un nivel de
sistema claramente
definido
–
61508, parte 5
Anexo E
En la tabla F.2 se hacen recomendaciones sobre el uso de las distintas técnicas/medidas de Integridad
Básica (BI) y para cada Nivel de Integridad de Seguridad (SIL). Las recomendaciones se clasifican como
"HR", "R", "-" y "NR". El significado de estos términos es el siguiente:
"HR", este símbolo significa que la técnica o la medida es altamente recomendable (Highly
Recommended) para este nivel de integridad de la seguridad. Si no se utiliza esta técnica o medida,
debería detallarse el motivo por el que no se utiliza, a menos que se seleccione una combinación
aprobada de técnicas.
"R", este símbolo significa que la técnica o la medida es recomendable (Recommended) para este nivel
de integridad de la seguridad.
"–" Este símbolo significa que no existen recomendaciones ni a favor ni en contra relativas al uso de
esta técnica o esta medida.
"NR", este símbolo significa que la técnica o la medida no es recomendable (Highly Recommended) para
este nivel de integridad de la seguridad. Si se utiliza esta técnica o medida, debería detallarse la
justificación de su uso".
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 84 -
Tabla F.2 – Técnicas/Métodos para Integridad Básica (BI) y
Niveles de integridad de la seguridad (SIL)
TÉCNICA/MEDIDA
Integridad Básica (BI)
SIL 1
SIL 2
SIL 3
SIL 4
1.
Análisis preliminar de peligros
HR
HR
HR
HR
HR
2.
Análisis por árbol de fallos
–
R
R
HR
HR
3.
Diagramas de Markov
–
R
R
HR
HR
4.
FMECA
–
R
R
HR
HR
5.
HAZOP
R
R
R
HR
HR
6.
Diagramas causa-efecto
–
R
R
HR
HR
7.
Árbol de Eventos
–
R
R
R
R
8.
Diagrama de bloques de la fiabilidad
–
R
R
R
R
9.
Análisis por zonas
–
R
R
R
R
10. Análisis de peligros de interfaz
R
R
R
HR
HR
11. Análisis de Fallos de Causa Común
R
R
R
HR
HR
12. Análisis histórico de eventos
–
R
R
R
R
13. Análisis de peligros de funcionamiento y
soporte
–
R
R
R
R
NOTA 1 Técnica 1, se aconseja considerar solamente la PHA, en las primeras etapas del desarrollo. Cuando se disponga de
información técnica precisa, durante el diseño, se preferirán los otros métodos.
NOTA 2 Las técnicas 2 y 3 pueden considerarse mutuamente excluyentes.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 85 -
UNE-EN 50126-2:2018
Anexo G (Informativo)
Funciones y responsabilidades clave en materia de seguridad del sistema
Tabla G.1 – Especificación de funciones para el Diseñador
Función: Diseñador
Responsabilidades:
1.
especificación de los requisitos
2.
desarrollar y mantener la especificación de requisitos
3.
administrar la especificación de requisitos
4.
garantizar la coherencia y la compleción dentro de la especificación de requisitos (con referencia a los
requisitos del usuario y al entorno final de la aplicación)
5.
garantizar que los requisitos y especificaciones se encuentran bajo la gestión de cambios y configuración,
incluidos el estado, la versión y el estado de autorización
6.
establecer y mantener la trazabilidad entre los requisitos
7.
transformar los requisitos especificados en soluciones aceptables
8.
controlar la arquitectura y las soluciones de diseño descendente
9.
definir y seleccionar métodos de diseño y herramientas de soporte
10. aplicar los principios y normas de diseño de seguridad
11. desarrollar, cuando proceda, especificaciones del subsistema.
12. mantener la trazabilidad hasta y desde los requisitos especificados
13. desarrollar y mantener la documentación de diseño
14. garantizar que los documentos de diseño están bajo el control de las modificaciones y de la configuración
15. garantizar la integridad y coherencia de la documentación de diseño
Competencias principales:
1.
ser competente en ingeniería de requisitos
2.
entender el rol global del sistema y el entorno de aplicación
3.
entender las técnicas analíticas y sus resultados
4.
entender las normas aplicables
5.
ser competente en ingeniería apropiada al área de aplicación
6.
ser competente en principios de diseño de la seguridad
7.
ser competente en análisis de diseño y en metodologías de ensayo del diseño
8.
poder trabajar dentro de los límites de las restricciones de diseño en un entorno determinado
9.
ser competente en el ámbito problemático
10. comprender todas las limitaciones impuestas por los subsistemas y los sistemas de interfaz
11. comprender todas las limitaciones impuestas por la implementación del sistema
12. ser competente en la implementación de los sistemas
13. entender las partes relevantes de la Norma EN 50126
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 86 -
Tabla G.2 – Especificación de funciones para el Verificador
Función: Verificador
Responsabilidades:
1.
desarrollar un plan de verificación (que puede incluir cuestiones relativas a la calidad) exponiendo qué
necesita verificarse y qué tipos de procesos (por ejemplo, revisiones, análisis, etc.) y ensayos se requieren
como prueba
2.
gestionar el proceso de verificación (revisión, integración y ensayos) y garantizar la independencia de las
actividades según sea necesario
3.
comprobar la adecuación (compleción, coherencia, corrección, relevancia y trazabilidad) de las pruebas
documentadas a partir de las revisiones, de la integración y de los ensayos con los objetivos de verificación
especificados
4.
desarrollar y mantener registros de las actividades de verificación
5.
elaborar un informe de verificación en el que se expongan los resultados de las actividades de verificación
y asegurarse de que se planifican las actividades de ensayo
6.
identificar las anomalías, clasificarlas en términos del riesgo (impacto) que suponen, y registrarlas y
comunicarlas al organismo competente de la gestión de las modificaciones para su evaluación y toma de
decisiones
7.
gestionar los ensayos para las actividades de verificación:
a)
desarrollar la especificación de ensayos (objetivos y ensayos)
b)
ejecutar los ensayos de acuerdo con la especificación y planificación de ensayos
c)
garantizar la trazabilidad de los objetivos de los ensayos con respecto a los requisitos especificados
del sistema
d)
garantizar la trazabilidad de los casos de ensayo con respecto a los objetivos de ensayo especificados
e)
garantizar la realización de los ensayos previstos y la realización de los casos de ensayo especificados
f)
identificar las desviaciones de los resultados previstos y registrarlos en los informes de ensayos
Competencias principales:
1.
ser competente en el ámbito en el que se lleven a cabo los ensayos, la integración y la verificación
2.
ser competente en varios enfoques/metodologías de verificación y ensayos y poder identificar el método o
la combinación de métodos más apropiada en un contexto determinado
3.
poder deducir casos de ensayo a partir de especificaciones determinadas
4.
ser competente para entender el diseño y la funcionalidad requeridos en varios niveles intermedios
5.
poder deducir los tipos de ensayos de integración a partir de un conjunto de funciones integradas
6.
poder deducir los tipos de verificación a partir de especificaciones determinadas
7.
tener capacidad de pensamiento analítico y buenas capacidades de observación
8.
entender las partes relevantes de la Norma EN 50126
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 87 -
UNE-EN 50126-2:2018
Tabla G.3 – Especificación de funciones para el Validador
Función: Validador
Responsabilidades:
1.
establecer una comprensión del sistema en el entorno de aplicación previsto
2.
desarrollar un plan de validación y especificar las tareas y actividades esenciales para la validación del
software y ponerse de acuerdo sobre este plan con el evaluador independiente de la seguridad, si se
cuenta con él/ella
3.
revisar los requisitos del sistema en relación a su uso/entorno previsto
4.
revisar el resultado en relación con los requisitos del sistema para asegurarse de que se cumplen todos
ellos
5.
evaluar la conformidad del proceso y del resultado en relación a los requisitos de esta norma europea
incluyendo el SIL (nivel de integridad de la seguridad) asignado
6.
revisar la corrección, coherencia y adecuación de la verificación y de los ensayos
7.
comprobar la corrección, coherencia y adecuación de los casos de ensayo y de los ensayos realizados
8.
asegurarse de que se llevan a cabo todas las actividades previstas en el plan de validación del sistema
9.
revisar y clasificar todas las desviaciones en términos de riesgo (impacto), registrarlas y comunicarlas al
organismo competente de la gestión de las modificaciones para su evaluación y toma de decisiones
10.
proporcionar una recomendación sobre la idoneidad del resultado para su uso previsto e indicar
cualquier restricción de la aplicación, según sea apropiado
11.
capturar las desviaciones con respecto al plan de validación del sistema
12.
realizar auditorías, inspecciones o revisiones del proyecto global (como instancias del proceso de
desarrollo genérico) según sea apropiado en varias fases del desarrollo
13.
revisar y analizar los informes de validación de otras aplicaciones genéricas, si se reutilizan para el
sistema en consideración
14.
revisar si las soluciones desarrolladas son trazables hasta los requisitos
15.
garantizar que se revisan los registros de situaciones peligrosas asociadas y los casos de no conformidad
y que se resuelven todas las situaciones peligrosas de manera adecuada bien sea mediante medidas que
las eliminen o con medidas de control/transferencia de los riesgos
16.
desarrollar un informe de validación
17.
expresar su acuerdo/desacuerdo para la publicación de los resultados
Competencias principales:
1.
ser competente en el dominio en el que se realice la validación
2.
ser competente en varios enfoques/metodologías de validación y poder identificar el método o la
combinación de métodos más apropiada en un contexto determinado
3.
poder deducir los tipos de pruebas de validación requeridas a partir de las especificaciones determinadas
teniendo en cuenta la aplicación prevista
4.
poder combinar diferentes fuentes y tipos de pruebas y sintetizar una vista global sobre la validez o sobre
las restricciones y limitaciones de la aplicación
5.
tener capacidad de pensamiento analítico y buenas capacidades de observación
6.
entender los requisitos de la Norma EN 50126
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 88 -
Tabla G.4 – Especificación de funciones para el Evaluador independiente de la seguridad
Función: Evaluador independiente de la seguridad
Responsabilidades:
1.
cuando se les encargue una evaluación independiente de la seguridad, garantizar que no intervengan ni
directamente ni como representantes autorizados en el diseño, fabricación, construcción,
comercialización, funcionamiento o mantenimiento del sistema objeto de una evaluación independiente.
(Esto no excluye la posibilidad de intercambio de información técnica)
2.
establecer una comprensión del sistema en el entorno de aplicación previsto
3.
desarrollar un plan de evaluación y comunicárselo a la autoridad de seguridad y/o a la organización del
cliente (organismo contratante del evaluador)
4.
evaluar la conformidad del proceso y del resultado en relación a los requisitos de esta norma europea
incluyendo el SIL (nivel de integridad de la seguridad) asignado
5.
evaluar la competencia del personal del equipo de proyecto y de la organización para desarrollos
6.
evaluar las actividades de verificación y validación y las pruebas justificativas
7.
evaluar los sistemas de gestión de la calidad adoptados para los desarrollos
8.
evaluar la configuración y el sistema de gestión de las modificaciones y las pruebas de su uso y aplicación
9.
identificar y evaluar en términos de riesgo (impacto) toda desviación de los requisitos en el informe de
evaluación
10.
evaluar que las auditorías de seguridad se han llevado a cabo y documentado de manera adecuada
11.
realizar inspecciones del proceso de desarrollo global según sea apropiado durante varias fases del
desarrollo
12.
dar una opinión profesional sobre la validez de los resultados para su uso previsto detallando las
restricciones, condiciones de aplicación y observaciones para el control de riesgos, según sea apropiado
13.
desarrollar y mantener registros e informes de acuerdo con el plan de evaluación
Competencias principales:
1.
ser competente en el dominio/tecnologías en el/las que se realice la evaluación
2.
estar habilitado o poseer una licencia de una autoridad de seguridad reconocida
3.
esforzarse para adquirir de forma continua/tener niveles suficientes de experiencia en materia de
principios de seguridad y en la aplicación de los principios dentro del dominio de aplicación
4.
ser competente para comprobar que se haya aplicado un método o una combinación de métodos
apropiado/s en un contexto determinado
5.
ser competente para comprender los procesos pertinentes de gestión de la seguridad, de recursos
humanos y de gestión de la calidad para cumplir los requisitos de la Norma EN 50126
6.
ser competente en enfoques y metodologías de evaluación independientes
7.
tener capacidad de pensamiento analítico y buenas capacidades de observación
8.
poder combinar diferentes fuentes y tipos de pruebas y sintetizar una vista global sobre la validez o sobre
las restricciones y limitaciones de la aplicación
9.
conocer el sistema general, incluido su entorno de aplicación
10.
entender los requisitos de la Norma EN 50126
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 89 -
UNE-EN 50126-2:2018
Tabla G.5 – Especificación de funciones para el Director de proyecto
Función: Director de proyecto
Responsabilidades:
1.
asumir la responsabilidad total de la gestión del proyecto en relación con RAMS
2.
garantizar que se cumple el sistema de gestión de la calidad y la independencia de los funciones en el
proyecto de acuerdo con las partes relevantes de la Norma EN 50126 y que se comprueba la evolución en
relación a los planes previstos
3.
dedicar una cantidad suficiente de recursos en el proyecto a realizar tareas esenciales, incluyendo las
actividades de seguridad, teniendo en cuenta el espíritu de independencia necesario de las funciones
4.
garantizar que se ha nombrado a un validador apropiado para el proyecto como se define en la Norma
EN 50126
5.
ser el responsable del suministro e implantación del sistema y garantizar que también se cumplen y se
transmiten los requisitos de seguridad de las partes interesadas
6.
proporcionar suficiente tiempo para la implementación y el cumplimiento correcto de las tareas de
seguridad
7.
aprobar los productos de seguridad completos y parciales a entregar por el proceso de desarrollo
8.
garantizar que se mantienen registros y una trazabilidad suficientes durante la toma de decisiones
relacionadas con la seguridad
Competencias principales:
1.
comprender los requisitos de calidad, competencias, organización y gestión de las Normas EN 50126 y
EN ISO 9001
2.
entender los requisitos del proceso de seguridad
3.
poder ponderar diferentes opciones y entender el impacto en las características de la seguridad de una
decisión o de las opciones seleccionadas
4.
entender los requisitos del proceso de desarrollo
5.
entender los requisitos de otras partes relevantes de la Norma EN 50126
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 90 -
Anexo ZZ (Informativo)
Relación entre esta norma europea y los requisitos esenciales de la
Directiva 2008/57/CE
Esta norma europea ha sido elaborada bajo un Mandato dirigido a CENELEC por la Comisión Europea
y por la Asociación Europea de Libre Comercio, y dentro de su campo de aplicación cubre todos los
requisitos esenciales aplicables del Anexo III de la Directiva CE 2008/57/CE (denominada también
Directiva de Nuevo Enfoque 2008/57/CE sobre la interoperabilidad del sistema ferroviario).
Una vez que esta norma sea citada en el Diario Oficial de la Unión Europea bajo dicha Directiva y haya
sido adoptada como norma nacional en al menos un estado miembro, la conformidad con los capítulos
normativos de esta norma dados en la tablas ZZ.1 para "Control, mando y señalización", tabla ZZ.2 para
"Locomotoras de ferrocarril convencional y material rodante de pasajeros", tabla ZZ.3 para "Energía" y
tabla ZZ.4 para "Infraestructura" confiere, dentro de los límites del campo de aplicación de esta norma,
presunción de conformidad con los correspondientes requisitos esenciales de esa Directiva y de los
Reglamentos de la AELC asociados.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 91 -
UNE-EN 50126-2:2018
Tabla ZZ.1 – Correspondencia entre esta norma europea, la ETI "Control, mando y señalización"
(Regulación (UE) 2016/919 de 27 de mayo de 2016) y la Directiva 2008/57/CE
Apartados de esta
norma europea
Capítulo/§/puntos de la ETI Requisitos esenciales (RE) de
CMS
la Directiva 2008/57/CE
3.2. Aspectos específicos de
los subsistemas de control,
mando y señalización
3.2.1. Seguridad
3.2.2. Fiabilidad y
disponibilidad
Es aplicable toda la
norma.
(Debe aplicarse junto
con la Norma
EN 50126-1).
1. Requisitos generales
1.1 Seguridad
1.1.1
1.1.3
1.2 Fiabilidad y disponibilidad
Comentarios
Debería actualizarse
la referencia a la
norma en la ETI
(tabla A 3) y en su
guía de aplicación
4.2. Especificaciones
2. Requisitos específicos para
funcionales y técnicas de los cada subsistema
subsistemas
2.3. Control-mando y
4.2.1. Características de
señalización
seguridad del control-mando 2.3.1. Seguridad
y señalización relevantes para
la interoperabilidad
4.2.1.1. Seguridad
4.2.1.2.
Fiabilidad/disponibilidad
4.5. Reglas de mantenimiento
4.5.1. Responsabilidad del
fabricante de los equipos
4.5.2. Responsabilidad del
solicitante de la verificación
del subsistema
6. Evaluación de la
conformidad y/o idoneidad
para el uso de los
componentes y verificación
de los subsistemas
6.2. Componentes de
interoperabilidad
6.2.1. Procedimientos de
evaluación de los
componentes de
interoperabilidad de controlmando y señalización
6.3. Subsistemas de controlmando y señalización
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 92 -
Tabla ZZ.2 – Correspondencia entre esta norma europea, la ETI "Locomotoras y material
rodante de viajeros" (Regulación (UE) Nº 1302/2014 del 18 de noviembre de 2014) y la
Directiva 2008/57/CE
Apartados de esta
norma europea
Es aplicable toda la
norma.
(Debe aplicarse junto
con la Norma
EN 50126-2).
Capítulo/§/puntos de la Requisitos esenciales (RE)
ETI LOC & PAS
de la Directiva 2008/57/CE
4.2. Especificación
funcional y técnica del
subsistema
Comentarios
1. Requisitos generales
1.1 Seguridad
1.1.1
1.1.3
1.2 Fiabilidad y
disponibilidad
Debería actualizarse la
referencia a la norma en la
guía de aplicación de la
ETI
2. Requisitos específicos para
cada subsistema
2.4. Material rodante
2.4.1. Seguridad
2.4.2 Fiabilidad y
disponibilidad
Únicamente los elementos
que tienen requisitos
relacionados con la
seguridad y/o la
fiabilidad/disponibilidad,
según se indica en el
capítulo 3 de la ETI
6.2.3.5. Evaluación de la
conformidad para los
requisitos de seguridad
Tabla ZZ.3 – Correspondencia entre esta norma europea, la ETI "Energía"
(Regulación (UE) Nº 1301/2014 del 18 de noviembre de 2014) y la Directiva 2008/57/CE
Apartados de esta
norma europea
Es aplicable toda la
norma.
(Debe aplicarse junto
con la Norma
EN 50126-2).
Capítulo/§/puntos de la Requisitos esenciales (RE)
ETI ENE
de la Directiva 2008/57/CE
4.4. Normas de
explotación
4.5. Normas de
mantenimiento
4.6. Competencias
profesionales
4.7. Condiciones de
seguridad y salud
Comentarios
1. Requisitos generales
1.1 Seguridad
1.1.1
1.1.3
1.2 Fiabilidad y
disponibilidad
2. Requisitos específicos para
cada subsistema
2.2. Energía
2.2.1. Seguridad
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
- 93 -
UNE-EN 50126-2:2018
Tabla ZZ.4 – Correspondencia entre esta norma europea, la ETI "Infraestructura"
(Regulación (UE) Nº 1299/2014 del 18 de noviembre de 2014) y la Directiva 2008/57/CE
Apartados de esta
norma europea
Es aplicable toda la
norma.
(Debe aplicarse junto
con la Norma
EN 50126-2).
Capítulo/§/puntos de la ETI Requisitos esenciales (RE) de
INF
la Directiva 2008/57/CE
2.5. Relación con el sistema
de gestión de seguridad
4.4. Normas de explotación
4.5. Normas de
mantenimiento
4.6. Cualificaciones
profesionales
4.7. Condiciones de seguridad
y salud
Comentarios
1. Requisitos generales
1.1 Seguridad
1.1.1
1.1.3
1.2 Fiabilidad y disponibilidad
2. Requisitos específicos para
cada subsistema
2.1. Infraestructura
2.1.1. Seguridad
ADVERTENCIA: Los productos incluidos en el campo de aplicación de esta norma pueden estar
afectados por otros requisitos o Directivas de la UE.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
UNE-EN 50126-2:2018
- 94 -
Bibliografía
EN ISO 9001, Quality management systems. Requirements (ISO 9001).
ISO/IEC 90003, Software engineering. Guidelines for the application of ISO 9001:2008 to computer
software.
ISO/IEC Guide 51, Safety aspects. Guidelines for their inclusion in standards.
JORF n°0077 du 31 mars 2017, Décret n° 2017-440 du 30 mars 2017 relatif à la sécurité des
transports publics guidés.
A. Kuhlmann, Einführung in die Sicherheitstechnik (Introduction into Safety Technology), Friedr.
Vieweg & Sohn, Verlag TÜV Rheinland, 1981.
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR
Para información relacionada con el desarrollo de las normas contacte con:
Asociación Española de Normalización
Génova, 6
28004 MADRID-España
Tel.: 915 294 900
info@une.org
www.une.org
Para información relacionada con la venta y distribución de las normas contacte con:
AENOR INTERNACIONAL S.A.U.
Tel.: 914 326 000
normas@aenor.com
www.aenor.com
organismo de normalización español en:
Este documento ha sido adquirido por EGISMEX S DE RL DE CV el 2019-10-25.
Para poder utilizarlo en un sistema de red interno, deberá disponer de la correspondiente licencia de AENOR