Norma Española
UNE-EN 50126-1
Septiembre 2018
Aplicaciones ferroviarias
Especificación y demostración de la fiabilidad, la
disponibilidad, la mantenibilidad y la seguridad
(RAMS)
Parte 1: Procesos RAMS genéricos
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-1
Aplicaciones ferroviarias
Especificación y demostración de la fiabilidad, la disponibilidad, la mantenibilidad
y la seguridad (RAMS)
Parte 1: Procesos RAMS genéricos
Railway Applications. The Specification and Demonstration of Reliability, Availability, Maintainability
and Safety (RAMS). Part 1: Generic RAMS Process.
Applications ferroviaires. Spécification et démonstration de la fiabilité, de la disponibilité, de la
maintenabilité et de la sécurité (FDMS). Partie 1: Processus FMDS générique.
Esta norma es la versión oficial, en español, de la Norma Europea EN 50126-1:2017.
Esta norma anulará y sustituirá a las Normas UNE-EN 50126-1:2005,
UNE-EN 50126-1:2005 Erratum:2007, UNE-EN 50126-1:2005 CORR:2006 y
UNE-EN 50126-1:2005 CORR:2010 antes de 2020-07-04.
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 29926: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-1
NORMA EUROPEA
EUROPEAN STANDARD
NORME EUROPÉENNE
EUROPÄISCHE NORM
Octubre 2017
ICS 29.280; 45.020
Sustituye a EN 50126-1:1999
Versión en español
Aplicaciones ferroviarias
Especificación y demostración de la fiabilidad, la disponibilidad,
la mantenibilidad y la seguridad (RAMS)
Parte 1: Procesos RAMS genéricos
Railway Applications. The Specification
and Demonstration of Reliability,
Availability, Maintainability and Safety
(RAMS). Part 1: Generic RAMS Process.
Applications ferroviaires. Spécification
et démonstration de la fiabilité, de la
disponibilité, de la maintenabilité et de
la sécurité (FDMS). Partie 1: Processus
FMDS générique.
Bahnanwendungen. Spezifikation und
Nachweis von Zuverlässigkeit,
Verfügbarkeit, Instandhaltbarkeit und
Sicherheit (RAMS). Teil 1: Generischer
RAMS Prozess.
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-1:2018
-4-
Índice
Prólogo europeo .................................................................................................................................8
0
Introducción ........................................................................................................................9
1
Objeto y campo de aplicación..................................................................................... 10
2
Normas para consulta ................................................................................................... 11
3
Términos y definiciones............................................................................................... 11
4
Abreviaturas..................................................................................................................... 23
5
5.1
5.2
5.2.1
5.2.2
5.2.3
5.3
5.3.1
5.3.2
5.3.3
RAMS en ferrocarriles ................................................................................................... 24
Introducción ..................................................................................................................... 24
Aproximación sistémica a varios niveles............................................................... 25
Conceptos de jerarquía del sistema ......................................................................... 25
Requisitos y características del sistema ................................................................ 27
Definición de un sistema.............................................................................................. 27
Visión general del sistema ferroviario ................................................................... 27
Introducción ..................................................................................................................... 27
Partes interesadas en un sistema ferroviario ...................................................... 28
Estructura del sistema ferroviario y asignación de los requisitos de
RAMS ................................................................................................................................... 29
RAMS en ferrocarriles y calidad del servicio........................................................ 29
Elementos de RAMS en ferrocarriles ....................................................................... 29
Factores que influyen en RAMS en ferrocarriles ................................................ 32
Generalidades .................................................................................................................. 32
Clases de fallos................................................................................................................. 32
Determinación de los factores de influencia específicos detallados
para ferrocarril ............................................................................................................... 33
Factores humanos .......................................................................................................... 37
Especificación de los requisitos de RAMS en ferrocarriles ............................. 40
Generalidades .................................................................................................................. 40
Especificación de RAMS ................................................................................................ 40
Enfoque basado en riesgos .......................................................................................... 40
Estrategia para la reducción de riesgos ................................................................. 41
Introducción ..................................................................................................................... 41
Reducción de los riesgos relacionados con la seguridad ................................. 41
Reducción de los riesgos relacionados con RAM ................................................ 42
5.4
5.5
5.6
5.6.1
5.6.2
5.6.3
5.6.4
5.7
5.7.1
5.7.2
5.8
5.9
5.9.1
5.9.2
5.9.3
6
6.1
6.2
6.3
6.4
6.4.1
6.4.2
6.5
6.5.1
Gestión de RAMS en ferrocarriles. Requisitos generales ................................. 43
Introducción ..................................................................................................................... 43
Ciclo de vida del sistema en estudio ........................................................................ 44
Evaluación de riesgos.................................................................................................... 55
Requisitos organizativos ............................................................................................. 56
Introducción ..................................................................................................................... 56
Requisitos .......................................................................................................................... 57
Aplicación de esta norma y adaptabilidad al campo de aplicación y
tamaño del proyecto...................................................................................................... 58
Requisitos generales ..................................................................................................... 58
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-1:2018
6.5.2
6.5.3
6.5.4
6.6
6.7
6.7.1
6.7.2
6.7.3
6.8
6.8.1
6.8.2
Caso de sistemas complejos con diferentes niveles jerárquicos ................... 60
Renovación dentro de los sistemas existentes .................................................... 61
Reutilización o adaptación de un sistema con aceptación previa ................ 61
Requisitos generales de la documentación de RAMS ........................................ 62
Verificación y validación.............................................................................................. 63
Introducción ..................................................................................................................... 63
Verificación ....................................................................................................................... 63
Validación.......................................................................................................................... 64
Evaluación independiente de la seguridad ........................................................... 65
Objetivos ............................................................................................................................ 65
Actividades ....................................................................................................................... 66
7
7.1
7.2
7.2.1
7.2.2
7.2.3
7.3
7.3.1
7.3.2
7.3.3
7.4
7.4.1
7.4.2
7.4.3
7.5
7.5.1
7.5.2
7.5.3
7.5.4
7.6
7.6.1
7.6.2
7.6.3
7.7
7.7.1
7.7.2
7.7.3
7.7.4
7.8
7.8.1
7.8.2
7.8.3
7.9
7.9.1
7.9.2
7.9.3
7.9.4
7.10
7.10.1
7.10.2
Ciclo de vida de RAMS ................................................................................................... 68
Generalidades .................................................................................................................. 68
Fase 1: Concepto ............................................................................................................. 68
Objetivos ............................................................................................................................ 68
Actividades ....................................................................................................................... 68
Entregables ....................................................................................................................... 69
Fase 2: Definición del sistema y contexto operativo ......................................... 69
Objetivos ............................................................................................................................ 69
Actividades ....................................................................................................................... 69
Entregables ....................................................................................................................... 74
Fase 3: Análisis y valoración de riesgos ................................................................. 74
Objetivos ............................................................................................................................ 74
Actividades ....................................................................................................................... 75
Entregables ....................................................................................................................... 79
Fase 4: Especificación de los requisitos del sistema .......................................... 79
Objetivos ............................................................................................................................ 79
Actividades ....................................................................................................................... 80
Entregables ....................................................................................................................... 81
Tareas específicas de validación............................................................................... 81
Fase 5: Arquitectura y asignación de los requisitos del sistema ................... 82
Objetivos ............................................................................................................................ 82
Actividades ....................................................................................................................... 82
Entregables ....................................................................................................................... 84
Fase 6: Diseño e implementación ............................................................................. 84
Objetivos ............................................................................................................................ 84
Actividades ....................................................................................................................... 84
Entregables ....................................................................................................................... 85
Tareas de verificación específicas ............................................................................ 86
Fase 7: Fabricación ........................................................................................................ 87
Objetivos ............................................................................................................................ 87
Actividades ....................................................................................................................... 87
Entregables ....................................................................................................................... 87
Fase 8: Integración ......................................................................................................... 88
Objetivos ............................................................................................................................ 88
Actividades ....................................................................................................................... 88
Entregables ....................................................................................................................... 89
Tareas de verificación específicas ............................................................................ 89
Fase 9: Validación del sistema ................................................................................... 90
Objetivos ............................................................................................................................ 90
Actividades ....................................................................................................................... 90
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-1:2018
7.10.3
7.11
7.11.1
7.11.2
7.11.3
7.12
-6-
7.12.1
7.12.2
7.12.3
7.12.4
7.13
7.13.1
7.13.2
7.13.3
Entregables ....................................................................................................................... 91
Fase 10: Aceptación del sistema................................................................................ 92
Objetivos ............................................................................................................................ 92
Actividades ....................................................................................................................... 92
Entregables ....................................................................................................................... 93
Fase 11: Explotación, mantenimiento y control del rendimiento del
sistema ............................................................................................................................... 93
Objetivos ............................................................................................................................ 93
Actividades ....................................................................................................................... 93
Entregables ....................................................................................................................... 97
Tareas de verificación específicas ............................................................................ 97
Fase 12: Retirada del servicio .................................................................................... 98
Objetivos ............................................................................................................................ 98
Actividades ....................................................................................................................... 98
Entregables ....................................................................................................................... 98
8
8.1
8.2
Caso de seguridad........................................................................................................... 98
Objeto de un caso de seguridad................................................................................. 98
Contenido de un caso de seguridad ......................................................................... 99
Anexo A (Informativo) Plan de RAMS............................................................................... 101
A.1
Generalidades ............................................................................................................... 101
A.2
Procedimiento .............................................................................................................. 101
A.3
Ejemplo de plan de RAMS básico ........................................................................... 101
A.4
Lista de técnicas ........................................................................................................... 103
Anexo B (Informativo) Ejemplos de parámetros para ferrocarriles .................... 107
B.1
Generalidades ............................................................................................................... 107
B.2
Parámetros de fiabilidad .......................................................................................... 107
B.3
Parámetros de mantenibilidad .............................................................................. 108
B.4
Parámetros de disponibilidad ................................................................................ 108
B.5
Parámetros de apoyo logístico ............................................................................... 110
B.6
Parámetros de seguridad ......................................................................................... 110
Anexo C (Informativo)
C.1
C.2
C.3
C.4
Calibración de la matriz de riesgos y categorías de
aceptación de riesgos ............................................................... 111
Generalidades ............................................................................................................... 111
Frecuencia de las categorías de ocurrencia ....................................................... 111
Categorías de gravedad ............................................................................................. 113
Categorías de aceptación de riesgos ..................................................................... 115
Anexo D (Informativo)
D.1
D.2
D.3
D.3.1
D.3.2
D.3.3
D.4
D.5
Directrices generales sobre la definición del
sistema........................................................................................... 117
Generalidades ............................................................................................................... 117
Definición del sistema en una aproximación sistemática iterativa .......... 117
Método para definir la estructura de un sistema ............................................ 117
Generalidades ............................................................................................................... 117
Lista de funciones ........................................................................................................ 117
Desglose funcional ...................................................................................................... 117
Parte/partes interesadas/límites de los sistemas .......................................... 118
Directrices generales sobre el contenido de la definición de un
sistema ............................................................................................................................ 119
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-1:2018
Anexo ZZ (Informativo) Relación entre esta norma europea y los requisitos
esenciales de la Directiva 2008/57/CE.............................. 120
Bibliografía ..................................................................................................................................... 124
Tabla 1 (informativa) – Tareas de RAMS para las fases del ciclo de vida 1 a 12 ...... 49
Tabla A.1 – Ejemplo de un esquema de plan básico de RAMS ...................................... 102
Tabla B.1 – Ejemplos parámetros de fiabilidad................................................................. 107
Tabla B.2 – Ejemplos de parámetros de mantenibilidad ............................................... 108
Tabla B.3 – Ejemplos de parámetros de disponibilidad ................................................. 108
Tabla B.4 – Ejemplos de parámetros de apoyo logístico ................................................ 110
Tabla B.5 – Ejemplos de parámetros de rendimiento de la seguridad ..................... 110
Tabla C.1 – Frecuencia de ocurrencia de incidencias peligrosas con ejemplos
para su cuantificación (basada en el tiempo) .................................................................... 112
Tabla C.2 – Frecuencia de ocurrencia de incidencias con ejemplos para su
cuantificación (basada en la distancia) ................................................................................ 113
Tabla C.3 – Categorías de gravedad (ejemplo relacionado con RAM) ....................... 113
Tabla C.4 – Categorías de gravedad (ejemplo 1 relacionado con RAMS) ................. 114
Tabla C.5 – Categorías de gravedad (ejemplo 2 relacionado con seguridad) ......... 114
Tabla C.6 – Categorías de gravedad económica (ejemplo) ............................................ 114
Tabla C.7 – Categorías de aceptación de riesgos (ejemplo 1 para decisiones
binarias) .......................................................................................................................................... 115
Tabla C.8 – Categorías de aceptación de riesgos (ejemplo 2) ....................................... 115
Tabla C.9 – Categorías de aceptación de riesgos (ejemplo relacionado con la
seguridad) ....................................................................................................................................... 115
Tabla D.1 – Ejemplos típicos de un desglose funcional .................................................. 118
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 ............................................................................................................ 121
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 .................... 122
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 .................................................................................................................................... 122
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 ........................................................................................... 123
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-1:2018
-8-
Prólogo europeo
Esta Norma EN 50126-1: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 a la Norma EN 50126-1:1999 que ha sido revisada técnicamente.
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
-9-
UNE-EN 50126-1:2018
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 (Señalización), Material Rodante y Suministro de Energía Eléctrica para
Ferrocarriles (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 estudio.
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.
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-1:2018
- 10 -
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.
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 estudio,
los requisitos obligatorios para dicho método tienen consecuentemente carácter obligatorio para la
gestión de la seguridad del sistema en estudio.
Esta norma europea consta de una parte principal (capítulo 1 a capítulo 8) y de los anexos A, B, C, D 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 1 de la Norma EN 50126
•
considera los procesos de RAMS, entendidos como fiabilidad, disponibilidad, mantenibilidad y
seguridad y su interacción;
•
considera los aspectos genéricos del ciclo de vida de RAMS. Las directrices generales de esta parte
se pueden utilizar en la aplicación de normas específicas;
•
define:
– un proceso, basado en el ciclo de vida del sistema y las tareas que contiene, para la gestión de
RAMS,
– un proceso sistemático, adaptable al tipo y tamaño del sistema en estudio, para especificar los
requisitos para RAMS y demostrar que se cumplen dichos requisitos;
• se ocupa de aspectos específicos ferroviarios;
• permite controlar y gestionar eficazmente los conflictos entre elementos de RAMS;
• no define:
– objetivos, cantidades, requisitos o soluciones de 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 para las partes interesadas en el sector ferroviario.
Esta parte 1 de la Norma EN 50126 es aplicable a aplicaciones ferroviarias, a saber Control, Mando y
Señalización, Material Rodante e Instalaciones Fijas, y específicamente:
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
- 11 -
UNE-EN 50126-1:2018
• a la especificación y demostración de RAMS 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; en particular:
– 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, 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
No aplicable.
3 Términos y definiciones
Para los fines de este documento, se aplican los términos y definiciones siguientes:
3.1 aceptación:
Estatus alcanzado por un producto, sistema o proceso una vez que se haya acordado que es apto para
su uso previsto.
3.2 accidente:
Acontecimiento o serie de acontecimientos no deseados que provocan la muerte, lesiones, pérdida de
un sistema o servicio, o efectos perjudiciales al medio ambiente.
[FUENTE: IEC 60050-821: FDIS2016, 821-12-02]
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-1:2018
- 12 -
3.3 aprobación:
Autorización para que un producto o proceso se comercialice o utilice con fines declarados o en
condiciones establecidas.
NOTA 1 La aprobación puede basarse en el cumplimiento de requisitos específicos o en el cumplimiento de procedimientos
específicos.
[FUENTE: EN ISO/IEC 17000:2004, 7.1]
[FUENTE: IEC 60050-902:2013, 902-06-01]
3.4 garantía (aseguramiento):
Certeza sobre la consecución de un objetivo perseguido. Declaración concebida para dar certidumbre.
3.5 auditoría:
Procedimiento sistemático, independiente y documentado para la obtención de registros,
declaraciones de hechos u otra información pertinente y para su evaluación objetiva con el fin de
determinar en qué medida se cumplen los requisitos especificados.
NOTA 1 Mientras que el término "auditoría" se aplica a sistemas de gestión, el término "evaluación" se aplica a organismos
de evaluación de la conformidad y de forma más general.
[FUENTE: EN ISO/IEC 17000:2004, 4.4, modificado. Las referencias a otros términos dentro de la
Norma ISO/IEC 17000 han sido sustituidas por hipervínculos a entradas en el VEI].
[FUENTE: IEC 60050-902:2013, 902-03-04]
3.6 disponibilidad, <de un producto>:
La capacidad que tiene un elemento de hallarse en situación de realizar una función requerida en
condiciones determinadas en un momento dado o durante un intervalo de tiempo señalado,
suponiendo que se faciliten los recursos externos requeridos.
[FUENTE: IEC 60050-821: FDIS2016, 821-05-82, modificado]
3.7 integridad básica:
Atributo de integridad para una función relacionada con la seguridad con una TFFR (tasa de fallo
funcional tolerable) superior a (menos exigente) 10-5 [h-1] o para una función no relacionada con la
seguridad.
3.8 riesgo colectivo:
Riesgo, resultante, por ejemplo, de un producto, proceso o sistema, al que una población o grupo de
personas está expuesto.
NOTA 1 El riesgo colectivo no debe confundirse con el riesgo de accidente con múltiples víctimas.
NOTA 2 El riesgo colectivo es la suma de los riesgos individuales a los que están expuestos los individuos de la población o
grupo. Sin embargo, el riesgo colectivo dividido por el número de personas solo proporcionará el riesgo individual
medio.
NOTA 3 Un grupo de personas podría ser, por ejemplo, el personal ferroviario que trabaja en un coche restaurante o todos
los pasajeros que usan una red en particular.
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-1:2018
3.9 producto comercial disponible en el mercado:
Producto definido por las necesidades del mercado, disponible comercialmente y cuya validez ha sido
demostrada por un amplio espectro de usuarios comerciales.
[FUENTE: EN 50128:2011, 3.1.3, modificado]
3.10 fallo de causa común:
Fallo de varios elementos, que de otro modo se considerarían independientes entre sí, provocado por
una sola causa.
[FUENTE: IEC 60050-192:2015, 192-03-18]
3.11 conformidad:
Demostración de que una característica o propiedad de un producto, sistema o proceso satisface los
requisitos especificados.
3.12 gestión de la configuración:
Proceso para identificar y documentar las características de las estructuras, sistemas y componentes
de una instalación (incluidos los sistemas y programas informáticos) y para garantizar que los cambios
en dichas características se desarrollan, evalúan, aprueban, publican, implementan, verifican, registran
e incorporan adecuadamente en la documentación de la instalación.
[FUENTE: IAEA 3, modificada)
[FUENTE: IEC 60050-395:2014, 395-07-52]
3.13 análisis de consecuencias:
Análisis de los acontecimientos que pueden producirse después de que se haya producido una
situación peligrosa.
[FUENTE: IEC 60050-821: FDIS2016, 821-12-14]
3.14 mantenimiento correctivo:
Mantenimiento realizado después de la identificación de averías destinado a reinstaurar una condición
determinada.
NOTA 1 El mantenimiento correctivo del software implica necesariamente que se realicen modificaciones.
[FUENTE: IEC 60050-192:2015, 192-06-06]
3.15 diseño:
Actividad aplicada para analizar y transformar requisitos específicos en soluciones aceptables.
[FUENTE: IEC 60050-821: FDIS2016, 821-12-16, modificado]
3.16 determinista:
Expresa que un comportamiento puede predecirse con certeza.
NOTA 1 Un suceso determinista en un sistema puede predecirse con certeza a partir de sucesos precedentes que sean
conocidos o sean los mismos que para un sistema equivalente probado.
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-1:2018
- 14 -
3.17 diversidad:
Existencia de dos o más medios o maneras diferentes de alcanzar un objetivo específico.
NOTA 1 La diversidad se utiliza específicamente como defensa contra los fallos de causa común. Puede lograrse contando
con sistemas que sean físicamente diferentes entre sí o mediante diversidad funcional (donde sistemas similares
alcancen un objetivo específico de diferentes maneras).
[FUENTE: IEC 60050-395:2014, 395-07-115]
3.18 entidad:
Persona, grupo u organización que desempeña uno de los roles definidos en esta norma.
3.19 víctima equivalente:
Expresión de víctimas mortales y lesiones ponderadas, así como una convención para combinar
lesiones y víctimas en una sola cifra para facilitar la valoración y comparación de riesgos.
3.20 error:
Discrepancia entre un valor o condición calculado, observado o medido y el valor o condición
verdadero, especificado o teóricamente correcto.
NOTA 1 La causa de un error puede encontrarse en un elemento defectuoso, por ejemplo, un error informático cometido por
un equipo informático defectuoso.
NOTA 2 Un error humano puede considerarse como una acción o inacción humana que puede producir un resultado no
deseado.
[FUENTE: IEC 60050-192:2015, 192-03-02]
3.21 fallo, <de un elemento>:
Pérdida de la capacidad para funcionar de la forma requerida.
NOTA 1 Calificaciones como catastrófico, crítico, mayor, menor, marginal e insignificante, pueden utilizarse para clasificar
los fallos según la gravedad de sus consecuencias, dependiendo la elección y las definiciones de los criterios de
gravedad, del campo de aplicación.
NOTA 2 Calificaciones como uso indebido, tratamiento indebido y debilidad, pueden utilizarse para categorizar fallos según
la causa del fallo.
[FUENTE: IEC 60050-192:2015, 192-03-01, modificado. Se ha omitido el contenido de la Nota 1 de
dicho apartado]
[FUENTE: IEC 60050-821:FDIS2016, 821-11-19]
NOTA 3 La distinción entre "fallo" y "avería" es que el primero es un suceso y el segundo un estado.
3.22 modo de fallo:
Manera en la que se produce un fallo.
[FUENTE: IEC 60050-192:2015, 192-03-17]
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-1:2018
3.23 tasa de fallo:
Límite de la fracción entre la probabilidad condicional de que en un instante de tiempo, T, el fallo de un
producto, suceda dentro de un determinado intervalo de tiempo (t, t + Δt) y la duración de ese
intervalo, Δt, cuando Δt tiende a cero, suponiendo que el elemento se halle en estado de
funcionamiento al principio del intervalo de tiempo.
NOTA 1 Para aplicaciones en las que la distancia recorrida o el número de ciclos de funcionamiento sea más relevante que el
tiempo, la unidad de tiempo puede sustituirse por la unidad de distancia o ciclos, según sea apropiado.
NOTA 2 El término "tasa de fallo" se utiliza a menudo con el sentido de "tasa media de fallo" definido en la entrada
192-05-07 del VEI.
[FUENTE: IEC 60050-821:FDIS2016]
3.24 avería, <en un sistema>:
Condición anormal que podría conducir a un error en el sistema.
NOTA 1 Una avería puede ser aleatoria o sistemática.
[FUENTE: IEC 60050-821:FDIS2016, 821-11-20]
3.25 función, <de un elemento>:
Acción o actividad especificada que puede realizarse por medios técnicos y/o humanos y tiene un
resultado definido en respuesta a una entrada de información definida.
NOTA 1 Una función puede especificarse o describirse sin referencia a los medios físicos para alcanzarla.
[FUENTE: IEC 60050-821:FDIS2016, 821-12-25, modificado]
3.26 seguridad funcional:
Parte de la seguridad global que depende de que las unidades funcionales y físicas funcionen
correctamente en respuesta a entradas de información.
[FUENTE: IEC 60050-351, 351-57-06]
3.27 producto genérico:
Producto independiente de las aplicaciones, que cumple con las condiciones límite, interfaces y
funcionalidades predefinidas (caja negra).
EJEMPLO
Mecanismos de cambio de agujas, contadores de ejes, sistemas operativos en tiempo real,
plataforma informática con seguridad intrínseca sin software de aplicación.
[FUENTE: IEC 60050-821:FDIS2016, 821-01-57]
3.28 peligro:
Condición que podría conducir a un accidente.
NOTA 1 La definición equivalente en el apartado 903-01-02 de la Norma IEC 60050-903:2013 utiliza la palabra "daños" en
lugar de "accidente".
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-1:2018
- 16 -
3.29 análisis de peligros:
Proceso de identificación de situaciones de peligro y análisis de sus causas, y formulación de los
requisitos para limitar la probabilidad de situaciones de peligro y sus consecuencias a un nivel
aceptable.
NOTA 1 En la evaluación de riesgos se tienen en cuenta aspectos de procesos similares. En esta norma, el término se aplica
en las fases del ciclo de vida después de la "especificación de requisitos".
[FUENTE: IEC 60050-821: FDIS2016, 821-11-23]
3.30 registro de peligros:
Documento en el que los peligros identificados, las decisiones tomadas, las soluciones adoptadas y su
implementación quedan registradas o referenciadas.
[FUENTE: IEC 60050-821:FDIS2016, 821-12-27]
3.31 tasa de peligros:
Tasa de ocurrencia de un peligro.
NOTA 1 Para una definición matemática detallada de "tasa", véase la definición de "tasa de fallo".
3.32 implementación:
Actividad aplicada para transformar diseños específicos en realidades.
[FUENTE: IEC 60050-821:FDIS2016, 821-12-29, modificado]
3.33 evaluación independiente de la seguridad:
Proceso para determinar si el sistema/producto cumple los requisitos de seguridad especificados y
para juzgar sobre si el sistema/producto es adecuado para el fin previsto en relación con la seguridad.
NOTA 1 En esta norma europea se definen los requisitos relativos a la independencia.
3.34 riesgo individual:
Riesgo resultante de, por ejemplo, un producto, proceso o sistema al que se ve expuesta una persona
individual.
NOTA 1 No se ha de confundir un riesgo individual con un accidente con una única víctima.
NOTA 2 Un riesgo colectivo es la suma de los riesgos individuales a los que están expuestas las personas en una población o
grupo. Sin embargo, el riesgo colectivo dividido por el número de personas solo proporcionará el riesgo individual
medio.
3.35 integración:
Proceso de ensamblaje de los elementos de un sistema de acuerdo con las especificaciones de
arquitectura y diseño, y ensayo de la unidad una vez integrada.
3.36 ciclo de vida:
Serie de etapas identificables por las que pasa un elemento, desde su concepción hasta su eliminació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 -
EJEMPLO
UNE-EN 50126-1:2018
El ciclo de vida típico de un sistema consta de las siguientes etapas: conceptualización y definición;
diseño y desarrollo; construcción, instalación y puesta en servicio; explotación y mantenimiento;
mejoras a mitad de su vida útil o prolongación de la vida útil; y retirada del servicio y eliminación.
NOTA 1 Las etapas identificadas variarán en función de la aplicación.
NOTA 2 En caso de que la implementación de mejoras a mitad de la vida útil o la prolongación de la vida útil conlleve la
realización de modificaciones, es necesario reconsiderar el concepto de ciclo de vida que se recoge en esta norma.
[FUENTE: IEC 60050-192:2015, 192-01-09]
3.37 mantenibilidad, <de un elemento>:
Capacidad de retención o restauración a un estado de explotación requerido en determinadas
condiciones de uso y mantenimiento.
NOTA 1 Dichas condiciones determinadas incluirían aspectos que afectan a la mantenibilidad, tales como: ubicación para el
mantenimiento, accesibilidad, procedimientos de mantenimiento y recursos de mantenimiento.
[FUENTE: IEC 60050-192:2015, 192-01-27]
3.38 mantenimiento:
Combinación de todas las acciones técnicas y de gestión destinadas a mantener un elemento en un
estado en el que pueda realizar una función requerida, o a devolverlo a dicho estado.
NOTA 1 Se supone que la gestión incluye actividades de supervisión.
[FUENTE: IEC 60050-192:2015, 192-06-01]
3.39 misión:
Descripción objetiva de la tarea fundamental desempeñada por un sistema.
3.40 perfil de una misión:
Líneas generales del rango y variación previstas en la misión respecto de parámetros tales como
tiempo, carga, velocidad, distancia, paradas, túneles, etc., en las fases de explotación del ciclo de vida.
3.41 anulación:
Imposición de un estado seguro tras la detección de una avería peligrosa.
[FUENTE: IEC 60050-821: FDIS2016, 821-12-38]
3.42 tiempo de anulación:
Intervalo de tiempo que comienza cuando se detecta la existencia de una avería y termina cuando se
impone un estado seguro.
[FUENTE: IEC 60050-821: FDIS2016, 821-12-39]
3.43 software preexistente:
Todo software desarrollado antes de la aplicación actualmente en cuestión se clasifica como software
preexistente, incluido el software comercial disponible en el mercado, el software de código abierto y
el software previamente desarrollado pero no conforme con esta norma europea.
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-1:2018
- 18 -
3.44 mantenimiento preventivo:
Mantenimiento realizado para mitigar la degradación y reducir la probabilidad de fallos.
NOTA 1 Véanse también los términos "mantenimiento basado en la condición" (entrada 192-06-07 del VEI) y
"mantenimiento programado" (entrada 192-06-12 del VEI).
[FUENTE: IEC 60050-192:2015, 192-06-05]
3.45 producto, <en ferrocarriles>:
Conjunto de elementos, interconectados para formar un sistema, un subsistema o un equipo, de
manera que cumplan con los requisitos especificados.
[FUENTE: IEC 60050-821: FDIS2016, 821-12-40, uso específico modificado]
3.46 gestión de proyectos:
Dirección técnica y/o administrativa de un proyecto, incluidos los aspectos de RAMS.
3.47 jefe de proyecto:
Entidad encargada de realizar la dirección de un proyecto.
[FUENTE: EN 50128:2011, 3.1.21]
3.48 responsable del servicio ferroviario:
Organismo responsable de la gestión global para la explotación de un sistema ferroviario dentro del
marco legal que corresponda.
NOTA 1 La gestión del responsable del servicio ferroviario en relación al conjunto del sistema o a las partes y actividades
relativas al ciclo de vida a veces se divide entre uno o más organismos o entidades. Por ejemplo:
–
el propietario o propietarios de una o más partes de los activos del sistema y sus agentes de compras;
–
el operador del sistema;
–
el encargado del mantenimiento de una o más partes del sistema.
NOTA 2 Normalmente, los responsables del servicio ferroviario son las empresas ferroviarias y los administradores de
infraestructuras. Esta división se basa en instrumentos legales o en acuerdos contractuales. Las responsabilidades
de cada parte se definen en las primeras etapas del ciclo de vida del sistema.
3.49 plan de RAM:
Conjunto documentado de actividades planificadas en el tiempo, recursos y acontecimientos que
sirven para implementar la estructura organizativa, las responsabilidades, procedimientos,
actividades, capacidades y recursos que juntos garantizan que un elemento cumpla los requisitos de
RAM específicos y pertinentes a un contrato o proyecto determinados.
3.50 proceso de gestión de RAMS:
Actividades y procedimientos que se siguen para permitir la identificación y el cumplimiento de los
requisitos de RAMS para un producto o una explotación.
NOTA 1 Proporciona una aproximación sistemática y sistémica para gestionar continuamente las RAMS a lo largo de todo el
ciclo de vida.
NOTA 2 Este proceso debería integrarse en un sistema de gestión a nivel organizativo.
NOTA 3 No es necesario que todos los medios para cumplir la función sean idénticos.
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-1:2018
3.51 fallo aleatorio:
Fallo imprevisible resultante de uno o más de los posibles mecanismos de degradación.
3.52 fiabilidad, <de un elemento>:
Capacidad para funcionar de la forma prevista, sin fallos, durante un intervalo de tiempo determinado
y en condiciones determinadas.
NOTA 1 La duración del intervalo de tiempo puede expresarse en unidades apropiadas para el elemento del que se trate, por
ejemplo, días de calendario, ciclos de trabajo, distancia recorrida, etc.
NOTA 2 Las condiciones determinadas incluyen aspectos que afectan a la fiabilidad, tales como: modo de explotación, niveles
de esfuerzo, condiciones ambientales y mantenimiento.
NOTA 3 La fiabilidad se puede cuantificar utilizando las medidas definidas en la Sección 192-05 del VEI, Conceptos
relacionados con la fiabilidad: medidas.
[FUENTE: IEC 60050-192:2015, 192-01-24]
3.53 crecimiento de la fiabilidad, <de un elemento>:
Proceso iterativo para la mejora de la fiabilidad.
[FUENTE: IEC 60050-192:2015, 192-12-03, modificado]
3.54 reparación:
Acción directa adoptada para provocar la restauración de una condición determinada.
NOTA 1 La reparación incluye la localización de averías (FUENTE: IEC 60050-192:2015, 192-06-19,), diagnóstico de averías
(FUENTE: IEC 60050-192:2015, 192-06-20), corrección de averías (FUENTE: IEC 60050-192:2015, 192-06-21) y
verificación de funcionamiento (FUENTE: IEC 60050-192:2015, 192-06-22).
[FUENTE: IEC 60050-192:2015, 192-06-14]
3.55 riesgo residual:
Riesgo remanente después de que se hayan adoptado medidas de control de riesgos.
[FUENTE: IEC 60050-903:2013, 903-01-11]
3.56 restauración:
Acción de devolver un elemento al estado en el que recupera la capacidad de funcionar de la forma
especificada tras una avería.
3.57 riesgo, <para RAMS en ferrocarriles>:
Combinación de la frecuencia esperada de pérdidas y el grado previsto de gravedad de las pérdidas.
3.58 análisis de riesgos:
Uso sistemático de la información disponible para identificar los peligros y estimar el riesgo.
[FUENTE: Guía ISO/IEC 51:2014, 3.10]
[FUENTE: IEC 60050-903:2013, 903-01-08]
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-1:2018
- 20 -
3.59 evaluación de riesgos:
Proceso integral que comprende el análisis y la valoración de riesgos.
[FUENTE: Guía ISO/IEC 51:2014, 3.12]
[FUENTE: IEC 60050-903:2013, 903-01-10].
3.60 enfoque basado en riesgos:
Proceso para garantizar la seguridad de los productos, procesos y sistemas mediante la consideración
de los peligros y sus riesgos correspondientes.
NOTA 1 El enfoque es aplicable a aspectos de RAM de forma análoga.
3.61 valoración de riesgos:
Procedimiento basado en el análisis de riesgos para determinar si se ha alcanzado el riesgo tolerable.
[FUENTE: Guía ISO/IEC 51:2014, 3.11]
[FUENTE: IEC 60050-903:2013, 903-01-09]
3.62 gestión de riesgos:
Aplicación sistemática de políticas, procedimientos y prácticas de gestión a las tareas de análisis,
valoración y control de riesgos.
3.63 estado seguro:
Condición que continúa preservando la seguridad.
[FUENTE: IEC 60050-821: FDIS2016, 821-12-50]
3.64 seguridad:
Ausencia de riesgos inaceptables.
NOTA 1 Riesgos relacionados con la salud humana o el medio ambiente.
[FUENTE: IEC 60050-903:2013, 903-01-19]
3.65 autoridad de seguridad:
Organismo responsable de la expedición de la autorización para la explotación del sistema relacionado
con la seguridad.
[FUENTE: IEC 60050-821:FDIS2016, 821-12-52]
3.66 barrera de seguridad:
Medios físicos o no físicos, que reducen la frecuencia de un peligro y/o de un posible accidente
derivado del peligro y/o mitiguen la gravedad de los posibles accidentes derivados del peligro.
NOTA 1 Este término se puede aplicar a los aspectos de RAM de forma similar.
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 -
UNE-EN 50126-1:2018
3.67 caso de seguridad:
Demostración documentada de que el producto (por ejemplo, un sistema, subsistema o equipo)
cumple los requisitos de seguridad especificados.
[FUENTE: IEC 60050-821: FDIS2016, 821-12-53]
3.68 función de seguridad:
Función cuyo único propósito es garantizar la seguridad.
NOTA 1 Una función relacionada con la seguridad es una función cuyo fallo afecta a la seguridad (para más detalles, véase la
definición de "relacionado con la seguridad"). Por tanto, todas las funciones de seguridad son funciones relacionadas
con la seguridad, pero no al contrario.
NOTA 2 Una función de seguridad puede formar parte de una o varias barreras de seguridad. Sin embargo, una función de
seguridad no tiene por qué implementar una barrera de seguridad.
3.69 integridad de la seguridad:
Capacidad de un sistema relacionado con la seguridad para realizar las funciones de seguridad
requeridas en todas las condiciones declaradas, dentro de un entorno operativo declarado y durante
una duración determinada.
[FUENTE: IEC 60050-821:FDIS2016, 821-12-54]
3.70 nivel de integridad de la seguridad:
Uno de varios niveles discretos definidos para especificar los requisitos de integridad de la seguridad
para las funciones relacionadas con la seguridad que han de asignarse a los sistemas relacionados con
la seguridad.
NOTA 1 El nivel de integridad de la seguridad con la cifra más alta tiene el nivel más alto de integridad de la seguridad.
NOTA 2 No es posible asignar un nivel de integridad de la seguridad a procesos relacionados con la seguridad u otras
medidas.
3.71 gestión de la seguridad:
Estructura de gestión que garantiza la correcta implantación del proceso de seguridad.
3.72 proceso de gestión de la seguridad:
Parte del proceso de gestión de RAMS que trata específicamente de los aspectos de seguridad.
3.73 plan de seguridad:
Conjunto documentado de actividades planificadas en el tiempo, recursos y acontecimientos que
sirven para implementar la estructura organizativa, las responsabilidades, procedimientos,
actividades, capacidades y recursos que juntos garantizan que un elemento cumplirá los requisitos de
seguridad específicos y pertinentes a un contrato o proyecto determinados.
[FUENTE: IEC 60050-821:FDIS2016, 821-12-57]
3.74 relacionado con la seguridad:
Que tiene responsabilidad en 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-1:2018
- 22 -
NOTA 1 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. Los requisitos atribuidos a la función pueden ser requisitos de
integridad sistemáticos o aleatorios.
[FUENTE: IEC 60050-821: FDIS2016, 821-01-73, se ha añadido la nota 1 original]
3.75 condiciones de aplicación relacionadas con la seguridad:
Condiciones que es necesario cumplir para que un sistema pueda integrarse y funcionar con
seguridad.
NOTA 1 Las condiciones de aplicación pueden ser, por ejemplo, las siguientes: restricciones en la explotación (por ejemplo,
límite de velocidad, duración máxima de utilización), normas operativas, restricciones de mantenimiento (por
ejemplo, intervalos de mantenimiento solicitados) o condiciones ambientales.
3.76 software:
Creación intelectual que comprende los programas, procedimientos, reglas, datos y toda la
documentación asociada en relación al funcionamiento de un sistema.
NOTA 1 El software de partida permite a la organización reproducir versiones bien definidas y su uso como información de
partida para la publicación de futuras versiones con mejoras o actualizaciones realizadas dentro de la fase de
mantenimiento.
[FUENTE: IEC 60050-192:2015, 192-01-07, modificado]
3.77 subsistema:
Parte de un sistema, que es en sí mismo un sistema.
[FUENTE: IEC 60050-192:2015, 192-01-04]
3.78 sistema:
Conjunto de elementos interrelacionados considerados como un todo en un contexto definido y
separados de su entorno.
[FUENTE: IEC 60050-351:2013, 351-42-08]
3.79 fallo sistemático:
Fallo que se produce invariablemente en condiciones específicas de manipulación, almacenamiento o
utilización.
NOTA 1 Un fallo sistemático puede reproducirse aplicando deliberadamente las mismas condiciones, aunque no todos los
fallos reproducibles son sistemáticos.
NOTA 2 La causa de un fallo sistemático se origina en la especificación, diseño, fabricación, instalación, explotación o
mantenimiento del elemento.
[FUENTE: IEC 60050-192:2015, 192-03-10]
3.80 seguridad técnica:
Parte de la seguridad que depende de las características de un producto, que se derivan de los
requisitos funcionales del sistema y/o del diseño del sistema.
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-1:2018
3.81 ensayos:
Determinación de una o varias características de un objeto para evaluar su conformidad, con arreglo a
un procedimiento.
NOTA 1 El término "ensayos" se aplica normalmente a materiales, productos o procesos.
[FUENTE: IEC 60050-902:2013, 902-03-02]
3.82 validación:
La confirmación, mediante la presentación de pruebas objetivas, de que se han cumplido los requisitos
para un uso o aplicación específicos previstos.
NOTA 1 El término "validado" se utiliza para designar el estatus correspondiente.
NOTA 2 Las condiciones de uso para la validación pueden ser reales o simuladas.
NOTA 3 En diseño y desarrollo, el término "validación" se refiere al proceso de examinar un elemento para determinar la
conformidad con las necesidades del usuario.
NOTA 4 La validación se realiza normalmente durante la fase final de desarrollo, bajo condiciones de explotación definidas,
aunque también puede realizarse en etapas anteriores.
NOTA 5 Se pueden llevar a cabo varias validaciones si existen diferentes usos previstos.
[FUENTE: IEC 60050-192:2015, 192-01-18]
3.83 verificación:
Confirmación, mediante la presentación de pruebas objetivas, de que se han cumplido los requisitos
especificados.
NOTA 1 El término "verificado" se utiliza para designar el estatus correspondiente.
NOTA 2 La verificación del diseño es la aplicación de ensayos y evaluaciones para evaluar la conformidad de un diseño con el
requisito especificado.
NOTA 3 La verificación se lleva a cabo en varias fases del ciclo de vida del desarrollo, examinando el sistema y sus
componentes para determinar la conformidad con los requisitos especificados al principio de esa fase del ciclo de
vida.
[FUENTE: IEC 60050-192:2015, 192-01-17, se ha modificado la nota 3]
4 Abreviaturas
CoP
Código de buenas prácticas (Code of Practice)
COTS
Comercial (Commercial off-the-shelf)
CEM
Compatibilidad electromagnética
IEM
Interferencia electromagnética
FC
Cobertura de averías (Fault Coverage)
AMFE
Análisis de los modos de fallo y de sus efectos
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-1:2018
- 24 -
FMECA
Modo de fallo y análisis de efectos y criticidad (Failure Mode, Effects and Criticality
Analysis)
FRACAS
Sistema de Comunicación de Fallos y Medidas Correctivas (Failure Reporting Analysis and
Corrective Action System)
AAF
Análisis por árbol de fallos
LAD
Retraso logístico y administrativo (Logistic and Administrative Delay)
LCC
Coste del ciclo de vida (Life cycle Cost)
MDT
Tiempo de caída medio (Mean Down Time)
MTBF
Tiempo Medio de Funcionamiento Entre Fallos (Mean Time Between Failures)
MTBM
Tiempo medio entre mantenimientos (Mean Time Between Maintenances)
MTTF
Tiempo medio hasta el fallo (Mean Time To Failure)
MUT
Tiempo medio operativo (Mean Up Time)
RAC
Criterios de aceptación de riesgos (Risk Acceptance Criteria)
RAM
Fiabilidad, disponibilidad y mantenibilidad (Reliability, availability and maintainability)
RAMS
Fiabilidad, Disponibilidad,
Maintainability and Safety)
RC
Cobertura de reparación (Repair Coverage)
SRAC
Condiciones de aplicación relacionadas con la seguridad (Safety-Related Application
Conditions)
TFFR
Tasa de fallo funcional tolerable (Tolerable Functional Failure Rate)
THR
Tasa de riesgo tolerable (Tolerable hazard rate)
Mantenibilidad
y
Seguridad
(Reliability,
Availability,
5 RAMS en ferrocarriles
5.1
Introducción
Este capítulo tiene por objeto describir el conjunto de conocimientos necesarios sobre RAMS para que
los usuarios de la norma puedan comprender de forma clara lo que se requiere para cumplir de
manera adecuada con las disposiciones del texto normativo de la norma.
El objetivo del proceso RAMS descrito en esta norma es garantizar que se cubran todos los aspectos de
RAMS a fin de garantizar la seguridad de las aplicaciones ferroviarias y evitar la pérdida de su valor.
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 -
UNE-EN 50126-1:2018
La seguridad y la prevención de la pérdida de valor del servicio se logran más eficazmente cuando los
factores de RAMS se controlan continuamente a lo largo de un proyecto desde su inicio hasta su puesta
en funcionamiento, en lugar de añadir sistemas correctivos en etapas posteriores.
Esta norma europea define un proceso de gestión, basado en el ciclo de vida del sistema, que permitirá
el control de los factores de RAMS específicos para aplicaciones ferroviarias. Este proceso de gestión
de RAMS se describe en los apartados siguientes, conteniendo requisitos los apartados 5.6 a 5.8. El
capítulo 6 recoge los requisitos de forma detallada.
Las RAMS en ferrocarriles son una de las principales contribuciones al valor del servicio prestado por
el responsable del servicio ferroviario. Las RAMS están definidas por varios elementos contributivos;
por consiguiente, este capítulo se estructura de la siguiente manera:
a)
los apartados 5.2 y 5.3 ofrecen una visión general de la aproximación sistémica y la definición del
sistema en el contexto de los ferrocarriles;
b) en el apartado 5.4 se examina la relación entre RAMS en ferrocarriles y el valor del servicio
prestado;
c)
el apartado 5.5 describe los elementos de RAMS en ferrocarriles y sus interacciones;
d) los apartados 5.6 a 5.9 examinan aspectos de RAMS en ferrocarriles, a saber:
– los factores que influyen y los medios para alcanzar los objetivos de RAMS,
– especificación de los requisitos de RAMS,
– riesgo e integridad de la seguridad.
5.2
Aproximación sistémica a varios niveles
5.2.1
Conceptos de jerarquía del sistema
Dentro de esta norma, la secuencia "sistema, subsistema, componente" se utiliza para demostrar la
descomposición de un sistema en sus partes constituyentes. El límite preciso de cada elemento
(sistema, subsistema y componente), ya sea físico o funcional, dependerá del diseño del sistema en
cuestión. El propio sistema está contenido en un entorno operativo.
El comportamiento y el estado del sistema pueden cambiar si se produce un cambio en la
funcionalidad o interacción de un subsistema o componente. Un sistema responde a entradas de
información para producir salidas de información específicas, interactuando con un entorno.
La utilización de los términos sistema y subsistema puede depender del punto de vista adoptado. Algo
considerado como un sistema por las personas que lo desarrollaron puede ser considerado como un
subsistema por las personas que lo utilizan como parte de su sistema. Esta diferencia de puntos de
vista se entiende con el concepto de sistemas anidados en la jerarquía del sistema, como se muestra de
forma esquemática en la figura 1.
De acuerdo con el concepto de sistemas anidados, los sistemas se construyen a su vez con sistemas
más pequeños, que a su vez se construyen con sistemas más pequeños y así sucesivamente.
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-1:2018
- 26 -
Para mayor comodidad, los sistemas anidados a varios niveles se manejan generalmente sobre la base
de agrupaciones de sistemas en niveles sucesivos de una jerarquía. El ejemplo de la figura 1 es una
jerarquía de tres niveles que consta de un "sistema en estudio" (subsistema D) que contiene
subsistemas y/o componentes interrelacionados (W, X, Y, y Z) y donde el propio sistema se encuentra
junto con sus subsistemas y/o componentes interrelacionados (A, B y C) dentro un sistema que los
contiene o matriz (por ejemplo, sistema de frenado, sistema de señalización o incluso el sistema
ferroviario en su conjunto). Esto proporciona visibilidad a los tres niveles y permite tener en cuenta:
– las interacciones e interfaces entre el "sistema en estudio" y sus "hermanos", es decir, los
subsistemas/componentes interrelacionados; y
– las influencias e interacciones entre el "sistema en estudio" y su entorno (es decir, el "sistema que
lo contiene" o "sistema matriz").
Las funciones de un sistema son las acciones o actividades realizadas por el sistema en su conjunto.
Las funciones y la estructura proporcionan la visión "interna" de las propiedades del sistema que
producen las respuestas y las propiedades externas y son responsabilidad del organismo/entidad
responsable del diseño del sistema. El entorno consiste en todo aquello que pueda influir o verse
influidos por el sistema. Esto incluye cualquier elemento al que el sistema se conecte mecánicamente,
eléctricamente o por otros medios, las interferencias electromagnéticas, esfuerzos térmicos, etc. El
entorno también incluirá personas y procedimientos que puedan afectar o verse afectados por el
funcionamiento del sistema.
La comprensión de los límites entre el sistema en estudio y su entorno y las interacciones con sus
subsistemas interrelacionados es un requisito previo para comprender cómo los fallos del sistema
podrían provocar un accidente y cuáles son los peligros relacionados con dichos fallos.
Figura 1 – Ilustración de la jerarquía del sistema
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 -
5.2.2
UNE-EN 50126-1:2018
Requisitos y características del sistema
Los requisitos del sistema se obtienen de diversas fuentes. Los requisitos pueden clasificarse por
categorías, pero no es posible una categorización única e inequívoca. Por lo tanto, la siguiente
clasificación es a título ilustrativo:
– Requisitos funcionales: se implementa un sistema para el cumplimiento de determinadas funciones
que son fundamentales para el sistema y la razón principal de su creación. Dependiendo del diseño
del sistema, también podrían ser necesarios requisitos adicionales para asegurar la explotación
adecuada del sistema. Los requisitos fundamentales y los requisitos adicionales en su conjunto se
denominan "Requisitos funcionales". Estos expresan el comportamiento del sistema y podrían
tener que complementarse con propiedades que clasifiquen su comportamiento (por ejemplo,
fiabilidad, seguridad, precisión, temporización, etc.) y con requisitos de rendimiento expresados en
términos de valores límite de los parámetros funcionales (por ejemplo, velocidad máxima, duración
del servicio, tiempo de respuesta, precisión, etc.).
– Requisitos contextuales: podría ser necesaria una clasificación adicional de la relación entre el
sistema y su entorno mediante requisitos contextuales. Los requisitos contextuales abordarían
cuestiones tales como el perfil de la misión del sistema, el mantenimiento y la logística, los factores
humanos (por ejemplo, la cualificación personal), el entorno de los procedimientos, los costes, etc.
– Requisitos técnicos: la implementación técnica del sistema puede generar requisitos adicionales
que no derivan de las funciones del sistema, sino de su implementación técnica. Estos requisitos se
denominan "Requisitos técnicos". Dichos requisitos tienen un impacto en la estructura del sistema.
Los requisitos técnicos podrían abordar cuestiones tales como la mantenibilidad, las condiciones
ambientales, las amenazas potenciales creadas por la tecnología/equipo independientemente de
sus funciones previstas (por ejemplo, presencia de bordes afilados, presencia de tensión eléctrica,
presencia de material combustible, etc.).
Un diseño detallado implica la creación técnica de los subsistemas y equipos que implementen los
requisitos para el sistema en estudio. Esto conduce al perfeccionamiento de los requisitos para
garantizar la compatibilidad entre los diferentes subsistemas/equipos, y a la implementación de
requisitos mejorados para garantizar la coherencia con los requisitos técnicos y contextuales.
5.2.3
Definición de un sistema
Un sistema comprende no solo sus componentes técnicos, sino también la interacción con los seres
humanos que lo desarrollan, operan y mantienen. Por tanto, el objetivo de las actividades especificadas
en el apartado 7.3.2 es garantizar que estas interacciones se incluyen en la definición y documentación
del sistema, teniendo en cuenta el concepto de jerarquía del sistema explicado en el apartado 5.2.
En el anexo D se ofrecen directrices generales para la definición del sistema.
5.3
Visión general del sistema ferroviario
5.3.1
Introducción
El apartado 5.3 da una perspectiva del sistema ferroviario, de las partes interesadas que participan en
él y de algunos de los conceptos subyacentes y de las consideraciones relativas a RAMS (por ejemplo,
riesgos y peligros). La comprensión del sistema y de sus elementos es esencial para la gestión de RAMS
en ferrocarriles.
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-1:2018
5.3.2
- 28 -
Partes interesadas en un sistema ferroviario
Dependiendo del entorno sociopolítico y de la estructura organizativa y de gestión del sistema
ferroviario del que se trate, pueden participar en las fases del ciclo de vida del sistema varias partes
interesadas que desempeñan funciones diferentes. Para los propósitos de esta norma, las partes
interesadas se dividen en las siguientes categorías principales:
– empresas ferroviarias (responsable del servicio ferroviario);
– administradores de infraestructuras (responsable del servicio ferroviario);
– mantenedores;
– proveedores ferroviarios;
– autoridades de seguridad.
En lo que respecta al proceso RAMS, cuando se desarrollan productos antes de identificar a un cliente,
los proveedores ferroviarios podrían tener que asumir algunas de las funciones del responsable del
servicio ferroviario.
Las funciones y responsabilidades de estas partes interesadas pueden subcontratarse a otras partes
interesadas o subcontratistas, dependiendo de:
– consideraciones sociales, políticas o jurídicas;
– tamaño y complejidad del sistema o subsistema en cuestión;
– consideraciones económicas, organizativas o de gestión.
Por tanto, es aconsejable identificar a todas las partes interesadas que pueden formar parte de esta
relación y examinar y documentar cómo se comparten entre ellas las funciones y responsabilidades en
relación a RAMS durante el ciclo de vida del sistema/subsistema en cuestión.
Los responsables del servicio ferroviario son los principales responsables de evaluar, controlar y
reducir los riesgos. Para ello, puede ser necesario obtener de los proveedores ferroviarios la
información pertinente relativa a RAMS sobre los productos.
NOTA A modo ilustrativo, se podría aplicar lo siguiente para un proyecto ferroviario que pueda afectar a la seguridad:
•
normalmente, el responsable del servicio ferroviario y/o una autoridad de seguridad (legal) establecen los
requisitos. Se trata, generalmente, de requisitos funcionales;
•
los proveedores ferroviarios suelen establecer los requisitos que se derivan de los productos (por ejemplo, debido
a la tecnología utilizada);
•
la autoridad responsable de la seguridad o el responsable del servicio ferroviario, en función del marco legal
pertinente, lleva a cabo la aprobación de la seguridad;
•
el responsable del servicio ferroviario lleva a cabo la aceptación de RAM;
•
los proveedores ferroviarios son normalmente los encargados de desarrollar soluciones, sus resultados y
verificaciones;
•
la validación implica normalmente tanto al responsable del servicio ferroviario como al proveedor para
ferrocarriles.
Los requisitos relativos a las funciones y responsabilidades se indican en el apartado 6.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
- 29 -
5.3.3
UNE-EN 50126-1:2018
Estructura del sistema ferroviario y asignación de los requisitos de RAMS
El sistema ferroviario, como cualquier otro sistema, se puede ver desde una perspectiva física o
funcional. No existe una única visión o división del sistema que satisfaga todas las necesidades, y la
visión finalmente adoptada dependerá del usuario y sus requisitos.
Basándose en el concepto de jerarquía del sistema (5.2), correspondería entonces al organismo/
entidad responsable de cada uno de los subsistemas distribuir o asignar los requisitos de RAMS entre
sus subsistemas/componentes. La definición de límites precisos y condiciones límite facilitará esta
asignación. A menudo es útil que esta tarea se lleve a cabo en cooperación con el organismo/entidad
responsable de los subsistemas/componentes para garantizar que los requisitos y objetivos sean
viables. Este proceso puede requerir varias iteraciones para garantizar la optimización del sistema
global.
Se puede utilizar un sistema de referencia similar que facilite esta asignación. En este caso, deberían
evaluarse las diferencias y su efecto sobre el resultado de RAMS para determinar su aceptabilidad. Las
diferencias pueden ser funcionales, técnicas, de entorno, operativas o del contexto de aplicación (por
ejemplo: límites y condiciones límite del sistema; niveles de competencia de mantenimiento y
explotación; interfaces funcionales y técnicas con el entorno, especialmente con otros sistemas).
5.4
RAMS en ferrocarriles y calidad del servicio
Las RAMS son características de la explotación a largo plazo de un sistema y se logran mediante la
aplicación de conceptos, métodos, herramientas y técnicas de ingeniería establecidos a lo largo del
ciclo de vida del sistema. Las RAMS de un sistema pueden caracterizarse como indicadores cualitativos
y cuantitativos del grado de fiabilidad del sistema, o los subsistemas y componentes que lo integran,
para funcionar como se especifica y estar disponibles y ser seguros durante un período de tiempo. Las
RAMS de un sistema, en el contexto de esta norma europea, son una combinación de características
interrelacionadas referentes a fiabilidad, disponibilidad, mantenibilidad y seguridad.
El objetivo de un sistema ferroviario es lograr un nivel definido de tráfico ferroviario en un momento
determinado, con seguridad y dentro de unos límites de costes específicos. El proceso RAMS en
ferrocarriles determina la confianza con la que el sistema puede alcanzar este objetivo. Las RAMS en
ferrocarriles tienen una clara influencia en la calidad con la que se ofrece el servicio al cliente. La
calidad del servicio se ve influida por otras características relacionadas con la funcionalidad y el
rendimiento, por ejemplo, la frecuencia del servicio, la regularidad del servicio y la estructura tarifaria.
La RAM también tiene un efecto significativo en el coste total del ciclo de vida.
5.5
Elementos de RAMS en ferrocarriles
Este apartado introduce la interacción entre los cuatro elementos de RAMS (fiabilidad, disponibilidad,
mantenibilidad y seguridad), en el contexto de los sistemas ferroviarios.
Los elementos de RAMS están interrelacionados en el sentido de que una debilidad en cualquiera de
ellos o la mala gestión de conflictos entre sus requisitos podría impedir tener un sistema fiable. Por
ejemplo, puede alcanzarse un objetivo de seguridad garantizando que el sistema entre en un estado
seguro (por ejemplo, todos los trenes parados) en caso de un fallo específico. El estado de seguridad
definido puede depender del contexto operativo/de mantenimiento (por ejemplo, un tren parado en
un andén y no en un túnel). Si existen circunstancias en las que dicho estado de seguridad tiene un
impacto adverso significativo en la fiabilidad/disponibilidad, podría ser necesaria una solución
diferente y optimizada para alcanzar los objetivos de RAM sin comprometer 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-1:2018
- 30 -
La consecución de los objetivos de disponibilidad en servicio se logrará optimizando la fiabilidad y la
mantenibilidad, teniendo en cuenta al mismo tiempo la influencia del mantenimiento de la seguridad.
Los requisitos relacionados pueden alcanzarse y controlarse mediante una combinación de medidas
de diseño e implementación, a través de las actividades de mantenimiento y de explotación a largo
plazo que se estén desarrollando, todo ello de acuerdo con el entorno del sistema.
La seguridad caracteriza la resistencia de un sistema ferroviario a actos vandálicos, actos de mala fe y
comportamientos humanos deliberadamente dañinos.
Figura 2 – Interrelación de los elementos de RAMS en ferrocarriles
Los conceptos técnicos de disponibilidad se basan en un conocimiento de:
a)
la fiabilidad en lo que se refiere a:
– todos los posibles modos de fallo del sistema en la aplicación y el entorno especificados,
– la frecuencia de ocurrencia o la probabilidad de cada modo de fallo,
– las consecuencias de cada modo de fallo;
b) la mantenibilidad en lo que se refiere a:
– la frecuencia y el tiempo para la realización de mantenimientos planificados o no planificados,
– el tiempo para la detección e identificación de las averías,
– el tiempo para la restauración del sistema averiado (mantenimiento no planificado);
c)
la explotación y el mantenimiento en lo que se refiere a:
– todos los modos de explotación posibles y el mantenimiento requerido (teniendo en cuenta los
costes), a lo largo del ciclo de vida del sistema,
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-1:2018
– el factor humano,
– las herramientas, instalaciones y procedimientos para el mantenimiento efectivo del sistema.
Los conceptos técnicos de seguridad se basan en el conocimiento de:
d) todos los posibles accidentes y peligros asociados que puedan resultar de un fallo en el sistema, o
de las propiedades o características del sistema, en todos los modos de explotación,
mantenimiento y condiciones del entorno;
e)
las características de cada peligro;
f)
los fallos relacionados con la seguridad en lo que se refiere a:
– todos los modos de fallo del sistema que pudieran suponer un peligro (modos de fallo
relacionados con la seguridad),
– la frecuencia de ocurrencia o la probabilidad de cada uno de los modos de fallo del sistema
relacionados con la seguridad,
– la secuencia y/o coincidencia de situaciones, fallos, estados de explotación, condiciones del
entorno, etc., en la aplicación, que pueden provocar un accidente (es decir, peligro de que se
produzca un accidente),
– la frecuencia de ocurrencia o la probabilidad de situaciones, fallos, estados de explotación,
condiciones del entorno, etc., relevantes para la aplicación;
g)
el mantenimiento de las partes del sistema relacionadas con la seguridad en lo que se refiere a:
– la facilidad de realización de tareas de mantenimiento de aquellos aspectos o partes del
sistema o sus componentes que estén asociados a un peligro o a un modo de fallo relacionado
con la seguridad,
– posibles errores que se produzcan durante las operaciones de mantenimiento de las partes del
sistema relacionadas con la seguridad,
– tiempo para devolver el sistema a un estado seguro;
h) la explotación del sistema y mantenimiento de las partes del sistema relacionadas con la
seguridad en lo que se refiere a:
– los factores humanos que influyen en el mantenimiento y la explotación,
– las herramientas, instalaciones y procedimientos para el mantenimiento efectivo del sistema y
para una explotación en condiciones de seguridad,
– controles y medidas eficaces para hacer frente a un peligro y mitigar sus consecuencias.
Los fallos en un sistema que funciona dentro de los límites de una aplicación y del entorno tendrán un
impacto en la fiabilidad, disponibilidad y seguridad del sistema, con el nivel de impacto determinado
por la funcionalidad y el diseño del sistema. El entorno y las normas de explotación también pueden
influir en estos efectos. En la figura 3 se muestran las relaciones.
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-1:2018
- 32 -
Figura 3 – Efectos de los fallos en un sistema
5.6
Factores que influyen en RAMS en ferrocarriles
5.6.1
Generalidades
Este apartado introduce y define un proceso para facilitar la identificación de los factores que influyen
en el resultado de RAMS de los sistemas ferroviarios, prestando especial atención a la influencia de los
factores humanos. Dichos factores y sus efectos suponen una entrada de información para la
especificación de los requisitos de RAMS para sistemas.
El resultado de RAMS de un sistema ferroviario se ve influido de tres maneras distintas, que pueden
interactuar entre sí:
• por fuentes de fallo introducidas internamente en el sistema en cualquier fase del ciclo de vida del
sistema;
• por fuentes de fallo impuestas al sistema durante su explotación; y
• por fuentes de fallo impuestas al sistema durante las actividades de mantenimiento.
Para crear sistemas fiables, es necesario identificar los factores que podrían influir en las RAMS del
sistema, evaluar su efecto y determinar la causa de estos efectos, gestionados a lo largo del ciclo de
vida del sistema, mediante la aplicación de controles adecuados para optimizar el rendimiento del
sistema.
5.6.2
Clases de fallos
Los fallos en un sistema, producto o proceso se clasifican como fallos aleatorios o fallos sistemáticos:
• Los fallos aleatorios se deben a causas que pueden describirse mediante distribuciones estadísticas.
• Los fallos sistemáticos son fallos debidos a errores en las actividades del ciclo de vida del sistema
que provocan que el producto, el sistema o el proceso falle de forma determinista en determinadas
combinaciones de entradas de información o en condiciones particulares (por ejemplo, la
combinación de entradas de información o/y situaciones desencadenantes como el incumplimiento
de las condiciones del entorno o de la aplicación). La principal causa de los fallos sistemáticos son
los errores humanos en las distintas etapas del ciclo de vida del sistema. Por tanto, los fallos
sistemáticos se tratan principalmente aplicando procesos, métodos y organización adecuados.
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 -
UNE-EN 50126-1:2018
Una característica distintiva importante entre fallos aleatorios y sistemáticos es que, en general, los
fallos aleatorios se deben a situaciones que se pueden controlar estadísticamente para poder estimar
su probabilidad de ocurrencia. Los fallos sistemáticos se deben a situaciones para las que no se
dispone de datos estadísticos, por lo que generalmente no se puede estimar su probabilidad de
ocurrencia.
La clara distinción entre fallos aleatorios y sistemáticos podría quedar difuminada a causa de las
siguientes observaciones:
• Los fallos sistemáticos son reproducibles, si se pueden reproducir las condiciones de manera
exacta. Si estas condiciones (la combinación de entradas de información que las activa) son de por
sí una situación aleatoria, la ocurrencia de las fallos sistemáticos también exhibe un
comportamiento aleatorio temporal visto desde el exterior.
• Un gran número de fallos, debidos a las condiciones del entorno (por ejemplo, temperatura,
humedad, etc.) y a influencias externas (CEM, vibraciones), pueden considerarse tanto sistemáticos
como aleatorios.
Muchos de los requisitos normativos establecidos en los capítulos 6 y 7 de esta norma tienen por
objeto evitar o mitigar los fallos sistemáticos.
5.6.3
Determinación de los factores de influencia específicos detallados para ferrocarril
Este apartado establece la base de un proceso para la determinación de aquellos factores que
ayudarán a conseguir con éxito un sistema que cumpla con los requisitos de RAMS especificados.
Los factores genéricos, incluidos los que aparecen en la figura 4, han de revisarse en el contexto del
sistema ferroviario en consideración.
Los factores de influencia detallados que influyen en las RAMS de un sistema específico se
determinarán mediante un proceso metódico que implique la evaluación de cada factor de influencia
genérico en el contexto del sistema específico.
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-1:2018
- 34 -
Figura 4 – Factores que influyen en RAMS en ferrocarriles
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-1:2018
El proceso de determinación de los factores de influencia detallados puede facilitarse (aunque no se ha
de limitar) mediante el uso de la siguiente lista de comprobación que abarca factores genéricos y
específicos del ferrocarril. Esta lista de comprobación no es exhaustiva y ha de adaptarse al campo de
aplicación y al propósito de la aplicación.
Se supone que el responsable del servicio ferroviario ha de especificar los factores aplicables cuando
realice una licitación.
a)
definición y diseño del sistema:
•
explotación del sistema:
– las tareas que realiza el sistema y las condiciones en las que se realizarán dichas tareas (perfil
de misión, procedimientos);
– la coexistencia de pasajeros, carga, personal y sistemas en el entorno de explotación;
– la mantenibilidad;
– los requisitos de vida del sistema, incluyendo la esperanza de vida del sistema, la intensidad
del servicio y los requisitos de coste del ciclo de vida.
•
categorías de fallos:
– los efectos de un fallo en un sistema ferroviario distribuido,
– los fallos aleatorios (degradación por esfuerzo, desgaste, sobreesfuerzo, etc.),
– los fallos sistemáticos (errores en los requisitos, deficiencias de diseño y realización,
deficiencias de fabricación, debilidades inherentes, errores de software, deficiencias en las
consignas de explotación, deficiencias de instalación, errores humanos, etc.);
b) condiciones de explotación:
•
entorno;
•
entorno físico;
•
las limitaciones impuestas por la infraestructura y los sistemas existentes al nuevo sistema en
estudio;
•
el alto nivel de integración de los sistemas ferroviarios en el entorno;
•
la limitada posibilidad de someter a ensayo a sistemas completos en el entorno ferroviario;
c)
condiciones de aplicación:
•
las limitaciones impuestas por el sistema a la explotación y al mantenimiento;
•
la necesidad de mantener los servicios ferroviarios durante las tareas del ciclo de vida (por
ejemplo, explotación en modo degradado durante el mantenimiento);
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-1:2018
- 36 -
•
factores humanos;
•
diagnóstico;
•
condiciones de instalación;
•
la integración de los sistemas existentes y los nuevos sistemas durante la puesta en servicio y
explotación.
d) condiciones de mantenimiento:
•
mantenimiento preventivo y correctivo;
•
factores humanos;
•
logística;
•
diagnóstico;
•
las condiciones de mantenimiento en tierra.
Se recomienda utilizar un enfoque diagramático para obtener factores detallados, como el uso de
diagramas de causa/efecto. En la figura 5 se muestra un ejemplo de diagrama simplificado de
causa/efecto.
Figura 5 – Ejemplo de determinación de las relaciones causa/efecto en un enfoque
diagramático2)
2) Basado en "Las 6 Ms" de K. Ishikawa (1960).
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-1:2018
En este diagrama, todos los elementos son causas que se combinan para producir el efecto
representado en la celda situada a la derecha junto a la punta de la flecha central.
• Personas: Cualquier persona involucrada en el proceso.
• Métodos: Explica cómo se lleva a cabo el proceso y los requisitos específicos para hacerlo, tales
como política, procedimientos, normas, reglamentos y leyes.
• Máquinas: Cualquier equipo, ordenador, herramienta, etc. que se requiera para realizar el trabajo.
• Materiales: Materias primas, piezas, bolígrafos, papeles, etc., utilizadas para producir el producto
final.
• Mediciones: Datos generados a partir del proceso que se utilizan para evaluar su calidad.
• Entorno: Las condiciones, tales como la ubicación, hora, temperatura y cultura en que opera el
proceso.
5.6.4
Factores humanos
Los factores humanos son un aspecto central dentro de un proceso de gestión de RAMS integrado. El
análisis de los factores humanos, en lo que se refiere a su efecto en RAMS del sistema, es inherente a la
"aproximación sistémica" aplicada en esta norma.
NOTA Es poco frecuente encontrar normas que proporcionen directrices generales al respecto, aunque pueden encontrarse
en algunas normas europeas, como en la Norma EN 614 sobre principios de diseño ergonómico.
Los factores humanos pueden definirse como el impacto de las características, expectativas y
comportamiento humanos en un sistema. Estos factores incluyen los aspectos anatómicos, fisiológicos
y psicológicos del ser humano. Los conceptos dentro de los factores humanos se utilizan para permitir
a las personas realizar el trabajo de manera eficiente y eficaz, teniendo debidamente en cuenta las
necesidades humanas en cuestiones como la salud, la seguridad y la satisfacción en el trabajo.
Cada ser humano puede reaccionar a distintas situaciones de diferentes maneras, lo que repercute en
el rendimiento de RAMS. La aplicación de RAMS en ferrocarriles requiere un control más riguroso de
los factores humanos a lo largo de todo el ciclo de vida del sistema, de lo que se requiere en muchas
otras aplicaciones industriales.
Los seres humanos tienen la capacidad de influir positiva o negativamente en RAMS de un sistema
ferroviario. Para maximizar la influencia positiva y reducir al mínimo la influencia negativa, debe
identificarse y gestionarse a lo largo del ciclo de vida la forma en que los factores humanos pueden
influir en RAMS en ferrocarriles. Esto debe incluir el impacto potencial de los factores humanos en
RAMS para ferrocarriles no solo en la fase de explotación, mantenimiento y control del rendimiento,
sino también en las demás fases del ciclo de vida del sistema. La influencia precisa de los factores
humanos en RAMS es específica para cada aplicación en consideración.
Se puede considerar el uso de normas específicas con directrices generales y métodos para analizar la
influencia de los factores humanos en RAMS.
EJEMPLO
Un ejemplo es la Norma VDI 4006 "Human Reliability" (fiabilidad humana).
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-1:2018
- 38 -
Se puede considerar que la influencia humana tiene aspectos aleatorios y sistemáticos. Todo ser
humano puede sufrir periodos ocasionales de disminución de su rendimiento. Cuando dichos periodos
tienen lugar durante fases de explotación y mantenimiento del ciclo de vida del sistema, tienden a
provocar fallos aleatorios: cuando ocurren en fases iniciales del ciclo de vida, pueden provocar fallos
sistemáticos en la fase de explotación.
La falta de competencia puede provocar errores humanos sistemáticos, en los que la falta de
conocimiento o comprensión pueden dar lugar a que se realice siempre la misma acción incorrecta en
circunstancias idénticas. Esto puede afectar a todas las fases del ciclo de vida.
El proceso de determinación de los factores de influencia humana puede sustentarse (aunque no se ha
de limitar) en los siguientes factores humanos. La siguiente lista de comprobación no es exhaustiva y
ha de adaptarse al campo de aplicación y al propósito de la aplicación.
a)
la distribución de las funciones del sistema entre el ser humano y la máquina;
b) el efecto sobre el rendimiento humano dentro del sistema de:
–
la interfaz humano/sistema;
–
el entorno, incluido el entorno físico y los requisitos ergonómicos;
–
los patrones de trabajo humanos;
–
la competencia de cada ser humano;
–
el diseño de las tareas humanas;
–
la interacción entre las personas;
–
el proceso de retroalimentación a las personas;
–
la estructura organizativa del sistema ferroviario;
–
la cultura ferroviaria;
–
la terminología ferroviaria;
–
los problemas derivados de la introducción de nuevas tecnologías.
c)
los requisitos del sistema derivados de:
–
la competencia de cada ser humano;
–
la motivación de las personas y el apoyo a sus aspiraciones;
–
la mitigación de los efectos de los cambios en el comportamiento humano;
–
las salvaguardas de la explotación;
–
espacio y tiempo de reacción humanos.
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-1:2018
d) los requisitos del sistema derivados de las capacidades de procesamiento de información de cada
ser humano, incluidos los siguientes:
–
las comunicaciones humano/máquina;
–
la densidad de transferencia de información;
–
la tasa de transferencia de información;
–
la calidad de la información;
–
la reacción humana a situaciones anormales;
–
la formación de las personas;
–
el apoyo a los procesos de toma de decisiones de las personas;
–
otros factores que contribuyan a crear tensión en las personas.
e)
el efecto en el sistema de los factores de la interfaz humano/sistema, incluidos:
–
el diseño y el funcionamiento de la interfaz humano/sistema; - el suministro de manuales de
usuario, etc.;
–
el efecto de los errores humanos;
–
el efecto del incumplimiento deliberado de las normas por parte de las personas (por ejemplo,
cuando un operador ignora una norma para ahorrar tiempo);
–
la participación e intervención humanas en el sistema;
–
la supervisión y anulación del sistema por parte de personas;
–
la percepción humana de un riesgo;
–
la participación humana en áreas críticas del sistema;
–
la capacidad humana para anticiparse a los problemas del sistema;
–
la reacción humana en diferentes modos de explotación (por ejemplo: normal, degradado o de
emergencia).
f)
factores humanos en todas las fases del ciclo de vida del sistema, incluyendo:
–
la competencia de cada ser humano;
–
la independencia de las personas durante las fases de diseño, verificación y validación;
–
la participación humana en las fases de verificación y validación;
–
la interfaz entre humanos y herramientas automatizadas;
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-1:2018
–
- 40 -
los procesos sistemáticos de prevención de fallos (por ejemplo: las medidas para garantizar la
integridad de la seguridad).
5.7
Especificación de los requisitos de RAMS en ferrocarriles
5.7.1
Generalidades
El objetivo principal de las actividades de RAMS es lograr un rendimiento del sistema que cumpla con
los requisitos de RAMS. Por tanto, la especificación de los requisitos de RAMS apropiados es de suma
importancia. En la Norma EN 50126-2 se ofrece información adicional sobre los métodos para obtener
y especificar los requisitos de seguridad del sistema.
Para alcanzar los requisitos de RAMS requeridos, los parámetros que influyen en el rendimiento RAMS
se deben controlar a lo largo de todo el ciclo de vida del sistema. El control efectivo requiere el
establecimiento de mecanismos y procedimientos definidos en los capítulos 6 y 7 para defenderse de
las fuentes de fallos. Dichas defensas han de tener en cuenta tanto los fallos aleatorios como los
sistemáticos.
5.7.2
Especificación de RAMS
La especificación de los requisitos de RAMS es un proceso complejo.
En el Anexo B se muestran ejemplos de parámetros típicos para caracterizar la fiabilidad,
disponibilidad, mantenibilidad, apoyo logístico y requisitos de seguridad de los sistemas ferroviarios.
Los parámetros específicos dependerán del sistema en estudio. Los parámetros de RAMS pertinentes
se deben acordar entre el responsable del servicio ferroviario y el proveedor para ferrocarriles en base
a la reglamentación establecida en el marco legal. Cuando los parámetros puedan expresarse en
dimensiones alternativas, se deben facilitar factores de conversión.
En el capítulo A.4 también se incluye una lista de herramientas adecuadas para las actividades de
RAMS. La selección de una herramienta adecuada dependerá del sistema en estudio y de factores como
la criticidad, novedad, complejidad, etc., del sistema.
5.8
Enfoque basado en riesgos
El enfoque basado en riesgos comprende la gestión de actividades de RAMS basadas en decisiones que
se derivan de consideraciones de existencia de riesgos. Su objetivo es identificar riesgos, derivar
requisitos y aplicar medidas para evitar o controlar dichos riesgos. Este enfoque es fundamental para
el proceso de gestión de RAMS y permite gestionar los riesgos relacionados con las RAMS a lo largo de
todo el ciclo de vida del producto.
El enfoque basado en riesgos se caracteriza por la evaluación de los criterios de aceptación de riesgos
en relación a la aceptabilidad de los riesgos residuales que quedan tras la implementación de medidas
de control. La valoración de riesgos y los criterios de aceptación aplicables deben definirse en base a la
definición del sistema (7.3).
Definir los criterios correctos de valoración de riesgos y de aceptación de los riesgos para la seguridad
es de vital importancia, ya que pueden referirse a situaciones de baja frecuencia y elevadas
consecuencias con el potencial de producir daños personales. En los apartados 6.3 y 7.4 se detallan los
requisitos para la valoración de riesgos de seguridad y los criterios de aceptació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
- 41 -
UNE-EN 50126-1:2018
Aunque el término riesgo se aplica más habitualmente a seguridad que a RAM, es aplicable a todos los
aspectos de RAMS. El riesgo es la combinación de dos elementos, cada uno de ellos aplicable a la
seguridad y a RAM:
• la frecuencia prevista de ocurrencia de una pérdida; y
• el grado de gravedad de dicha pérdida (consecuencia).
Al realizar actividades de RAM, la definición de riesgo puede completarse añadiendo la capacidad de
detectar fallos que afecten a la fiabilidad.
Las pérdidas pueden referirse a daños humanos, materiales y/o medioambientales. En el anexo C se
proporcionan detalles informativos.
Las pérdidas ocasionadas al medioambiente se suelen medir de forma cualitativa y, por lo general, no
se incluyen en los estudios de seguridad. Sin embargo, se recomienda consensuar su exclusión entre
las partes interesadas del sector ferroviario, incluida la autoridad competente en materia de
seguridad, siempre que no exista ninguna contradicción con el marco legal considerado.
5.9
Estrategia para la reducción de riesgos
5.9.1
Introducción
La estrategia para la reducción de riesgos se aplica a todos los riesgos relacionados con RAMS. El
objetivo de la estrategia es reducir los riesgos a un nivel aceptable siempre que se concluya que un
riesgo no es aceptable.
Los riesgos pueden disminuirse adoptando una combinación de medidas de prevención encaminadas a
reducir las pérdidas mediante la disminución de la frecuencia de las incidencias que resultan en
pérdidas, y a mitigar las pérdidas mediante la disminución de su gravedad. En la mayoría de los casos,
en general, se considera que la prevención es preferible a la mitigación.
Como perspectiva adicional a la aplicación del proceso de gestión de RAMS, se proporcionan las
siguientes directrices generales derivadas de la Guía ISO/IEC 51. Se centran en los riesgos
relacionados con la seguridad. No obstante, estas consideraciones pueden aplicarse a RAM también en
un sentido adaptado.
5.9.2
Reducción de los riesgos relacionados con la seguridad
Este apartado describe un enfoque basado en las mejores prácticas para reducir los riesgos de
seguridad en el que se aplican secuencialmente los siguientes pasos y se evalúan en base a su
factibilidad.
Un objetivo inicial de cualquier actividad relacionada con la seguridad es determinar si un peligro se
puede evitar en la práctica. Si no es posible, la siguiente consideración es si la frecuencia de ocurrencia
de dicho peligro podría reducirse a un nivel aceptable.
Si no es suficiente, el siguiente objetivo es asegurar que la frecuencia del peligro que pudiera
convertirse en un accidente se mantenga lo más baja posible.
Si esta no puede reducirse lo suficiente, el paso final es minimizar la gravedad de las pérdidas
resultantes del accidente (consecuencia del peligro).
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-1:2018
- 42 -
El enfoque y los pasos necesarios para garantizar la seguridad en el diseño de los equipos, así como
para establecer las normas de explotación son los siguientes:
a)
Hacer que la función en consideración sea segura.
El modo de fallo seguro es un concepto relativo, y los argumentos relacionados con este se pueden
proporcionar tras la realización de los análisis pertinentes. Algunos sistemas no tienen estados
seguros para todas las circunstancias.
EJEMPLO Detener automáticamente un tren si se detecta una emergencia suele ser seguro pero a veces
peligroso (por ejemplo, un tren en llamas detenido en un túnel).
b) En caso necesario, proporcionar funciones de seguridad adicionales u otras medidas.
Las funciones dedicadas al aumento de la seguridad se implementan siempre que sea necesario
para cumplir con los criterios de aceptación de riesgos pertinentes. Esto se aplica a todas las
tecnologías y también a las normas de explotación. El rendimiento de estas funciones de
seguridad ha de comprobarse adecuadamente en intervalos de tiempo lo suficientemente
frecuentes.
c)
Si es necesario, proporcionar además información relacionada con la seguridad.
De acuerdo con lo anterior, serán necesarias medidas adicionales, expresadas como limitaciones
adicionales que mejoren la seguridad (por ejemplo, en relación con la aplicación, el
mantenimiento o la explotación).
La Norma EN 50126-2 recoge requisitos y directrices generales adicionales para los aspectos de
seguridad.
5.9.3
Reducción de los riesgos relacionados con RAM
La reducción de los riesgos relacionados con RAM tiene por objeto reducir la pérdida de valor del
servicio prestado por el ferrocarril (por ejemplo, retrasos o cancelaciones de trenes). Este apartado
describe las formas en las que las actividades en cada fase del ciclo de vida del sistema pueden
contribuir a la reducción de riesgos relacionados con RAM.
Las principales maneras en que se pueden reducir los riesgos relacionados con RAM son:
• mejora de la fiabilidad, de modo que se produzcan menos fallos y, por consiguiente, menos
posibilidades de pérdidas;
• mejora en la disponibilidad, de modo que cuando se produzca un fallo, la pérdida resultante sea
menor.
Entre las medidas para mejorar la fiabilidad con respecto a los fallos aleatorios se incluyen las
siguientes:
• diseñar las tolerancias del sistema de forma que las pequeñas desviaciones de los parámetros con
respecto a sus valores nominales no provoquen un funcionamiento incorrecto (fase 6, Diseño e
implementació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
- 43 -
UNE-EN 50126-1:2018
• realizar diseños que no exijan que los componentes funcionen cerca de sus límites, por ejemplo,
carga, temperatura, etc. asignadas (fase 6, Diseño e implementación);
• aplicación de buenas prácticas de gestión de la calidad en la adquisición de materiales y en el
control de los procesos de fabricación e instalación (fase 7, Fabricación);
• control de estado del sistema y mantenimiento preventivo (fase 11, Explotación, mantenimiento y
control del rendimiento).
Existen cuatro estrategias principales para mejorar la disponibilidad:
• contar con sistemas duplicados o de emergencia para que un solo fallo no suponga una pérdida
total de funcionalidad (fase 5, Arquitectura y asignación de los requisitos del sistema);
• contar con medidas para la explotación en modo degradado (por ejemplo, reducción de la
frecuencia de los trenes o de su velocidad) en caso de fallo (fase 2, Definición del sistema y contexto
operativo, y fase 5, Arquitectura y asignación de los requisitos del sistema);
• mejora de la mantenibilidad del sistema, de modo que se reduzca el tiempo necesario para la
reparación y restablecimiento de las condiciones de explotación normales tras un fallo (fase 6,
Diseño e implementación);
• contar con recursos suficientes (como personal competente, equipos para realización de ensayos y
repuestos) para reducir el tiempo necesario para la reparación y el restablecimiento del
funcionamiento normal tras un fallo (fase 11, Explotación, mantenimiento y control del
rendimiento)
Estas estrategias pueden aplicarse de forma combinada. El orden en que figuran no implica un orden
de preferencia.
Los fallos sistemáticos son también una fuente significativa de riesgos relacionados con RAM y las
actividades en cada fase del ciclo de vida destinadas a prevenir los fallos sistemáticos, como la
especificación, verificación y validación, contribuyen a reducir los riesgos relacionados con RAM al
prestar la atención adecuada a los aspectos de RAM.
La consideración de RAM durante las fases 1 a 4 del ciclo de vida del sistema permite adoptar una
combinación adecuada de medidas y estrategias.
6 Gestión de RAMS en ferrocarriles. Requisitos generales
6.1
Introducción
Este capítulo establece requisitos generales para la gestión de RAMS en ferrocarriles.
El modelo del ciclo de vida del sistema en estudio se define como base para la gestión de RAMS,
incluyendo las normas de adaptabilidad.
En el capítulo 7 se detallan los requisitos relativos a las fases del ciclo de vida.
En la Norma EN 50126-2 se establecen los requisitos específicos para las actividades 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-1:2018
6.2
- 44 -
Ciclo de vida del sistema en estudio
El enfoque del ciclo de vida proporciona una estructura para planificar, gestionar, controlar y
supervisar todos los aspectos de un sistema, incluyendo RAMS, a medida que el sistema en estudio
avanza a través de las fases del ciclo de vida.
El objetivo del proceso RAMS es reducir la incidencia de fallos y/o sus consecuencias a lo largo del
ciclo de vida y, por tanto, minimizar el riesgo residual resultante de estos errores.
El modelo del ciclo de vida es fundamental para la implementación con éxito de esta norma. El modelo
de referencia se describe en la figura 6.
Esta norma representa el ciclo de vida de forma secuencial. Esta representación muestra las fases
individuales y las conexiones entre las fases. Existen otras representaciones del ciclo de vida que están
muy extendidas dentro de la industria y que pueden utilizarse siempre que sigan los requisitos de esta
norma.
El proceso RAMS general consta de 3 bloques principales:
– evaluación de riesgos (en base a la definición del sistema), incluida la especificación de los
requisitos de RAMS;
– implementación y demostración de que el sistema cumple los requisitos de RAMS especificados; y
– explotación, mantenimiento y retirada del servicio.
Además del flujo nominal del proceso entre las fases del ciclo de vida, el proceso general incluye:
a)
un bucle de retroalimentación (en el lado derecho de la figura 6):
–
pueden aparecer conocimientos nuevos o adicionales sobre riesgos durante cualquier fase del
proyecto que requiera reevaluar un riesgo;
b) bucles posteriores para el control de los requisitos de RAMS (en el lado izquierdo de la figura 6):
–
una reevaluación que permita saltarse algunas fases del proceso ordinario si los requisitos de
RAMS reconsiderados no afectan a dichas fases; o
–
en el peor de los casos, una reevaluación que exija la reformulación de las características
principales del proyecto (fase de concepción) si los requisitos no pueden cumplirse en modo
alguno.
Una consecuencia directa de estos bucles es que el flujo lógico de información y decisión es más
importante que el discurrir de las fases en el tiempo. Por tanto, en general, la evaluación de riesgos
debe confirmarse también al final del ciclo de vida.
Las tareas de proyecto generales quedan fuera del campo de aplicación de esta norma europea. Las
tareas de RAMS contribuyen a las tareas de proyecto generales para cada fase del ciclo de vida y los
requisitos para las tareas de RAMS se detallan en los apartados de esta norma europea.
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-1:2018
Figura 6 – Interrelación entre el proceso de gestión de RAMS y el ciclo de vida del sistema
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-1:2018
- 46 -
Figura 7 – Representación del ciclo en V
NOTA 1 El ciclo de vida propuesto en la figura 7 tiene una representación en "V". La rama descendente (lado izquierdo) es a
la que normalmente se denomina "desarrollo" y es un proceso de refinamiento que termina con la fabricación de los
componentes del sistema. La rama ascendente (lado derecho) está relacionada con el montaje, la instalación, la
entrega y, posteriormente, la explotación y mantenimiento de todo el sistema.
NOTA 2 Las tareas de verificación y validación se definen en el apartado 6.7.
Las fases del ciclo de vida son:
1.
Concepto (para más detalles, véase 7.2): deberían establecerse las características principales del
proyecto.
2.
Definición del sistema y contexto operativo (para más detalles, véase 7.3): descripción de las
características y funciones esenciales del sistema y aclaración de las interfaces con otros sistemas,
incluida las entradas de información que han de proporcionarse y los resultados previsibles. En
base a esto, se puede deducir el impacto en los parámetros de RAMS de sistemas anexos. Se
indican las condiciones de explotación (mantenimiento, entorno, etc.) que podrían perjudicar a la
función de seguridad (RAM) para garantizar que el operador las conozca. Se establece la gestión
de RAMS, incluyendo el plan de RAM y el plan 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
- 47 -
UNE-EN 50126-1:2018
3.
Análisis y valoración de riesgos (para más detalles, véase 7.4): se deberían seguir varios pasos
para decidir si un riesgo es tolerable (por ejemplo, para la seguridad: identificación de los peligros
asociados al sistema, identificación de las incidencias que conducen a peligros, determinación de
los riesgo asociados a los peligros, y establecimiento de procesos para la gestión continua de
riesgos). El análisis de riesgos es un paso continuo e iterativo y puede continuar en paralelo con
fases posteriores. Puede ser necesario definir otros requisitos de seguridad del sistema, inducidos
por los criterios de aceptación de riesgos, para reducir los riesgos a un nivel aceptable. Los
requisitos del sistema pueden obtenerse / existir a diferentes niveles.
4.
Especificación de los requisitos del sistema (para más detalles, véase 7.5): detallando los
requisitos iniciales del sistema (funciones previstas, incluyendo sus requisitos de RAMS) y los
derivados de la evaluación de riesgos en la fase 3, así como definiendo los criterios de aceptación
y especificando la demostración general de conformidad.
5.
Arquitectura y asignación de los requisitos del sistema (para más detalles, véase 7.6): asignación
de requisitos (incluidos todos los requisitos de RAMS) a los subsistemas.
NOTA 3 Los requisitos de los subsistemas pueden asignarse directamente si ya están disponibles a este nivel o si se derivan
del nivel de los requisitos del sistema.
6.
Diseño e implementación (para más detalles, véase 7.7): los subsistemas y componentes deberían
crearse de acuerdo con los requisitos asignados (incluyendo los requisitos de RAMS).
7.
Fabricación (para más detalles, véase 7.8): deberían fabricarse los subsistemas y componentes del
sistema y deberían establecerse y aplicarse disposiciones que garanticen el cumplimiento de
RAMS.
8.
Integración (para más detalles, véase 7.9): todos los subsistemas y componentes deberían
montarse e instalarse para formar el sistema completo.
9.
Validación del sistema (para más detalles, véase 7.10): debería validarse que el sistema, producto
o proceso cumple los requisitos de RAMS en combinación con medidas externas de reducción de
riesgos, confirmando que es adecuado para su uso específico previsto.
10. Aceptación del sistema (para más detalles, véase 7.11): para la entrada en servicio se requiere que
el sistema completo cumpla con el conjunto de requisitos de RAMS.
11. Explotación, mantenimiento y control del rendimiento del sistema (para más detalles, véase 7.12):
El objetivo de esta fase es explotar, mantener y controlar el producto, sistema o proceso de forma
que se mantenga el cumplimiento de los requisitos de RAMS del sistema. Esto incluye evaluar
continuamente el rendimiento de RAMS por parte del sistema y aplicar medidas correctivas si es
necesario.
12. Retirada del servicio (para más detalles, véase 7.13): el riesgo se controla durante la fase de
transición.
En caso de un nivel de sistema subordinado, el apartado 6.5 define qué fases es necesario repetir.
Principalmente, esto se refiere a todas las fases del ciclo de vida. Cada subsistema debería tratarse de
la misma manera en lo que se refiere a su nivel de detalle y dentro de los límites de su definición
específica de subsistema (método iterativo).
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-1:2018
- 48 -
Cuando la información sobre peligros y sus riesgos asociados en fases posteriores del ciclo de vida
presente peligros adicionales o un riesgo más elevado al previsto en una fase anterior del ciclo de vida,
se debe volver a mostrar la validez prolongada de la evaluación de riesgos inicial o se debe facilitar
una actualización de la evaluación de riesgos inicial.
Siempre que se introduzcan cambios una vez finalizada la fase de aceptación, se debe volver a aplicar
la fase de evaluación de riesgos del ciclo de vida, incluida la evaluación del impacto en las fases
posteriores del ciclo de vida.
NOTA 4 Los cambios introducidos durante el bloque "Implementación y demostración de la conformidad con los requisitos
de RAMS" del ciclo de vida de RAMS, podrían gestionarse tomando como referencia un proceso de gestión de control
de cambios (por ejemplo: resolución de errores).
La tabla 1 resume, a título informativo, la relación entre las tareas de RAMS que han de tenerse en
cuenta a lo largo del ciclo de vida del sistema en estudio. En el capítulo 7 se detallan los requisitos para
cada fase 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
- 49 -
UNE-EN 50126-1:2018
Tabla 1 (informativa) – Tareas de RAMS para las fases del ciclo de vida 1 a 12
Fase
Fase
Apartado
Tareas generales
Tareas de RAM
Tareas de seguridad
Estudiar las implicaciones generales
de seguridad en el sistema.
Estudiar las implicaciones generales
de RAM en el sistema.
1
Concepto
7.2
Estudiar el campo de aplicación,
contexto y propósito del sistema.
Estudiar el entorno del sistema.
Estudiar los requisitos previos de
RAM y el rendimiento de RAM en
situaciones anteriores en sistemas
similares/relacionados.
Estudiar la política de seguridad
actual y los objetivos de los
Estudiar la política actual de RAM y los responsables del servicio ferroviario
objetivos de los responsables del
pertinentes.
servicio ferroviario pertinentes.
Estudiar la legislación en materia de
Definir el campo de aplicación de los
seguridad.
requisitos de gestión de RAM para las
tareas de RAM posteriores del ciclo de Definir el campo de aplicación de los
vida del sistema.
requisitos de gestión de la seguridad
para las siguientes tareas de seguridad
del ciclo de vida del sistema.
Definir el sistema y el perfil de su
misión.
2
Definición del sistema y
contexto operativo
Estudiar los requisitos previos de
seguridad y el rendimiento de la
seguridad en situaciones anteriores en
sistemas similares/relacionados.
Establecer la política de seguridad.
Definir los límites del sistema.
Establecer la política de RAM.
Definir el campo de aplicación y los
requisitos de explotación.
Establecer el plan de RAM.
7.3
Establecer el plan de seguridad.
Establecer la organizació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-1:2018
Fase
Fase
- 50 -
Apartado
Tareas generales
Tareas de RAM
Tareas de seguridad
Realizar análisis de riesgos.
3
Análisis y valoración de
riesgos
Realizar análisis de riesgos.
7.4
Actualizar el plan de RAM.
Establecer un registro de peligros.
Actualizar el plan de seguridad.
Establecer un plan de evaluación
independiente de la seguridad
Establecer especificaciones de
requisitos de seguridad.
Establecer la especificación de los
requisitos de RAM.
4
Especificación de los
requisitos del sistema
7.5
Especificar los requisitos del sistema
Actualizar el plan de RAM.
Establecer un plan de validación para
los requisitos de RAM.
Establecer condiciones de aplicación
relacionadas con la seguridad.
Actualizar el registro de peligros.
Actualizar el plan de seguridad.
Establecer un plan de validación 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
- 51 -
Fase
Fase
Apartado
Tareas generales
UNE-EN 50126-1:2018
Tareas de RAM
Tareas de seguridad
Realizar el análisis de peligros.
Asignar requisitos de seguridad a los
subsistemas/componentes.
Definir la arquitectura del sistema.
5
Arquitectura y asignación
7.6
de los requisitos del sistema
Identificar los requisitos para la
integración de
subsistemas/componentes
preexistentes.
Definir criterios y procesos de
aceptación para los
subsistemas/componentes.
Asignar requisitos de RAM a los
subsistemas/componentes.
Actualizar el plan de RAM.
Actualizar el plan de validación de los
requisitos de RAM.
Actualizar las condiciones de
aplicación relacionadas con la
seguridad.
Actualizar el registro de peligros.
Actualizar el plan de seguridad.
Actualizar el plan de validación de los
requisitos de seguridad.
Diseñar subsistemas/componentes.
Planificar tareas de seguridad de fases
posteriores.
Preparar los procedimientos de
explotación y mantenimiento.
Definir medidas de formación para la
explotación y mantenimiento.
6
Diseño e implementación
7.7
Definir y establecer procesos de
fabricación para la producción de
subsistemas y componentes.
Definir y establecer el proceso de
integración del sistema.
Realizar análisis de peligros.
Planificar tareas de RAM de fases
posteriores.
Realizar el análisis de RAM.
Actualizar las condiciones de
aplicación relacionadas con la
seguridad.
Actualizar el plan de RAM.
Actualizar el registro de peligros.
Actualizar el plan de validación de los
requisitos de RAM.
Actualizar el plan de seguridad.
Preparar los procedimientos de
instalación y puesta en servicio.
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
Actualizar el plan de validación de los
requisitos de seguridad.
Preparar el caso de seguridad.
UNE-EN 50126-1:2018
Fase
Fase
- 52 -
Apartado
Tareas generales
Tareas de RAM
Tareas de seguridad
Establecer disposiciones que
garanticen el cumplimiento de la
seguridad.
Establecer disposiciones que
garanticen el cumplimiento de RAM.
7
Fabricación
7.8
Implementar y poner en marcha el
proceso de fabricación.
Actualizar el plan de RAM.
Actualizar el plan de validación de los
requisitos de RAM.
Actualizar las condiciones de
aplicación relacionadas con la
seguridad.
Actualizar el registro de peligros.
Actualizar el plan de seguridad.
Actualizar el plan de validación de los
requisitos de seguridad.
Actualizar el caso de seguridad.
Establecer un informe de integración
para los requisitos de seguridad.
Integrar subsistemas y componentes.
Demostrar la funcionalidad del
sistema.
8
Integración
7.9
Someter a ensayos y análisis al
sistema.
Organizar los mecanismos de soporte
del sistema.
Establecer un informe de integración
para los requisitos de RAM.
Actualizar las condiciones de
aplicación relacionadas con la
seguridad.
Actualizar el plan de RAM.
Actualizar el registro de peligros.
Actualizar el plan de validación de los
requisitos de RAM.
Actualizar el plan de seguridad.
Actualizar el plan de validación de los
requisitos de seguridad.
Actualizar 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
- 53 -
Fase
Fase
Apartado
Tareas generales
UNE-EN 50126-1:2018
Tareas de RAM
Tareas de seguridad
Establecer el informe de validación de
la seguridad.
Actualizar las condiciones de
aplicación relacionadas con la
seguridad.
Establecer el informe de validación.
9
Validación del sistema
7.10
Establecer procesos para la
adquisición y evaluación de datos de
explotación y mantenimiento.
Establecer el informe de validación de
Actualizar el registro de peligros.
RAM.
Actualizar el plan de seguridad.
Actualizar el plan de validación de los
requisitos de seguridad.
Actualizar el caso de seguridad.
Establecer un informe de evaluación
independiente de la seguridad.
Crear un registro de aceptación.
10
Aceptación del sistema
7.11
Verificar el registro de aceptación.
Evaluar la validación de RAM.
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
Asegurar la aprobación de las
condiciones de aplicación
relacionadas con la seguridad.
UNE-EN 50126-1:2018
Fase
Fase
- 54 -
Apartado
Tareas generales
Tareas de RAM
Implementar y mantener el proceso
FRACAS para la adquisición y registro
de los datos de rendimiento de RAM.
11
Explotación, mantenimiento
y control del rendimiento
7.12
del sistema
12
Retirada del servicio
7.13
Tareas de seguridad
Implementar y mantener procesos
para la adquisición y registro de datos
de rendimiento de la seguridad.
Proporcionar toda la información
necesaria para formular
planes/procedimientos de explotación
Realizar un análisis de impacto en
Mantener el proceso FRACAS y revisar
y mantenimiento.
caso de cambios y volver a aplicar el
periódicamente los registros FRACAS.
proceso si es necesario.
Implementar procedimientos de
Establecer registros para hacer un
explotación y mantenimiento.
Registros para hacer un seguimiento
seguimiento de las tareas de RAM
de las tareas de seguridad realizadas.
realizadas.
Registrar los cambios en la
configuración del sistema.
Establecer informes de análisis y
Informes de análisis y evaluación del
evaluación del rendimiento de la
rendimiento de RAM.
seguridad.
Establecer el plan de retirada del
servicio y realizar el informe
correspondiente.
Identificar el impacto en RAM de la
retirada del servicio y de la
eliminación.
NOTA La actividad de control de cambios o de gestión de la configuración se aplica a todas las fases del proyecto.
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
Identificar el impacto en la seguridad
de la retirada del servicio y la
eliminación.
- 55 -
6.3
UNE-EN 50126-1:2018
Evaluación de riesgos
Este apartado es relevante para la fase 3 del ciclo de vida y se basa en la definición del sistema de la
fase 2 del ciclo de vida. Puede ser necesario valorar la evaluación de riesgos en la fase 10 y/u 11 del
ciclo de vida. También se puede continuar según sea apropiado en distintas fases del ciclo de vida del
sistema.
El proceso de evaluación de riesgos se muestra en la figura 8. Comprende:
• el análisis de riesgos;
• la valoración de riesgos.
El análisis de riesgos es el uso sistemático de toda la información disponible para identificar peligros o
sus equivalentes RAM, las pérdidas potenciales relacionadas con dichos peligros y valorar los riesgos
asociados.
El análisis de riesgos distingue entre los peligros o sus equivalentes RAM que no necesitan un análisis
más a fondo, y los peligros o sus equivalentes RAM que necesitan un análisis más a fondo.
El siguiente texto es aplicable en caso de pérdidas relacionadas con los peligros y puede aplicarse
también a equivalentes RAM.
NOTA 1 El equivalente RAM a un peligro es una situación que podría ocasionar pérdidas económicas relacionadas con RAM.
Se debe llevar a cabo una evaluación de riesgos para el sistema en estudio. Para cada peligro
identificado o equivalente RAM, se debe decidir si el riesgo asociado puede considerarse "aceptable en
términos generales". Esta decisión debe justificarse y registrarse. Como criterio a tener en cuenta, los
riesgos resultantes de los peligros pueden clasificarse como "aceptables en términos generales"
cuando los riesgos son tan pequeños que no es razonable aplicar ninguna medida adicional. El
dictamen técnico para la calificación de una serie de riesgos como aceptables en términos generales
debe tener en cuenta que la contribución de todos los riesgos aceptables en términos generales no
supere un porcentaje definido del riesgo global.
NOTA 2 La elección de un riesgo como "aceptable en términos generales" puede incluir casos en los que no se produzcan
lesiones a seres humanos o casos en los que no haya consecuencias para la seguridad, sino únicamente para la
disponibilidad. En estos casos, los requisitos de RAM pueden seguir siendo aplicables.
Si en el análisis de riesgos se identifican casos con riesgos "aceptables en términos generales", no es
necesario especificar requisitos adicionales para dichos casos.
Si el análisis de riesgos llegara a la conclusión de que un riesgo no es "aceptable en términos
generales", la actividad de análisis de riesgos debe continuar eligiendo y aplicando un "principio de
aceptación de riesgos" (RAP, Risk Acceptance Principle) antes de aplicar la valoración de los riesgos.
Los tres principios de aceptación de riesgos son:
a)
uso de un código de buenas prácticas (CoP, Code of Practice);
b) comparación con un sistema similar como 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-1:2018
c)
- 56 -
estimación explícita del riesgo (ERE, Explicit Risk Estimation) (cualitativa o cuantitativa).
Una vez elegido y aplicado el principio de aceptación de riesgos, el proceso continúa con la valoración
del riesgo (determinando el cumplimiento de los criterios asociados al principio de aceptación de
riesgos seleccionado) y la especificación de los requisitos de seguridad.
El riesgo de seguridad admisible de un sistema ferroviario depende de los criterios de aceptación de
riesgos (RAC) establecidos por el marco jurídico o por el responsable del servicio ferroviario de
acuerdo con lo que se establezca en el marco legal.
NOTA 3 En la Norma EN 50126-2 se proporcionan detalles de seguridad, incluida la especificación de integridad básica e
integridad de la seguridad.
Figura 8 – Proceso para la evaluación de riesgos relacionados con las fases 3 y 4
(concernientes a la seguridad)
6.4
Requisitos organizativos
6.4.1
Introducción
El cumplimiento de los requisitos de esta norma se basa en estructuras y reglas organizativas,
implementadas por el órgano de gestión responsable, que permiten a su personal cumplir con
requisitos específicos y aseguran que se están siguiendo. Por tanto, esta norma se basa en el
compromiso y trabajo de los órganos de gestió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
- 57 -
UNE-EN 50126-1:2018
Las responsabilidades de las tareas en las distintas fases del ciclo de vida dependen de la relación
contractual y legal entre las partes implicadas, con funciones y responsabilidades afines definidas y
acordadas.
En el contexto de un proceso de contratación, deberían aclararse las funciones y responsabilidades
para llevar a cabo las tareas de RAMS. Las responsabilidades para llevar a cabo las tareas dependerán
del sistema en estudio y de las condiciones contractuales aplicables.
Muchas funciones dentro de una organización, tales como las de verificador, validador o evaluador, se
encargan de confirmar el resultado de RAMS establecidas por profesionales con otras funciones (por
ejemplo, un diseñador).
La independencia entre funciones puede ser necesaria para reducir la probabilidad de que existan
personas con diferentes funciones que trabajen con los mismos conceptos erróneos o cometan los
mismos errores. Esta forma de independencia puede lograrse empleando a diferentes personas en
diferentes funciones, pero normalmente no requiere que las funciones se ubiquen en diferentes partes
de la organización o en diferentes compañías.
También es importante que las personas en funciones que impliquen emitir juicios sobre la
aceptabilidad de un producto o proceso desde el punto de vista de la seguridad no se vean influidas
por la presión de sus compañeros o supervisores, ni por consideraciones de beneficios económicos.
En general, un mayor grado de riesgo para la seguridad requiere un mayor grado de independencia
para las distintas funciones.
Se puede asignar una determinada función (por ejemplo, diseñador, verificador, validador, evaluador)
a distintas partes para que se encarguen de cada uno de los tres bloques principales del ciclo de vida
(Evaluación de riesgos, Implementación y demostración de la conformidad, Explotación y
mantenimiento) definidos en el apartado 6.1.
La verificación y validación de la evaluación de riesgos es normalmente una tarea diferente de la
verificación y validación de la implementación y demostración de la conformidad, y pueden estar
sometidas a diferentes requisitos contractuales con conjuntos de documentación diferentes.
6.4.2
Requisitos
El proceso de gestión de RAMS se debe implementar bajo el control de una organización apropiada,
utilizando personal competente asignado a funciones específicas.
La evaluación y documentación de la competencia del personal, incluidos los conocimientos técnicos,
cualificaciones, experiencia pertinente y formación adecuada, se deben realizar de acuerdo con los
requisitos documentados que ha de definir la organización de gestión de RAMS.
El nivel de conocimientos técnicos, el grado de experiencia y la necesidad de actualizar o refrescar la
formación deben ser acordes a los requisitos de RAMS para la aplicación.
Se deben definir funciones y responsabilidades para las tareas en las distintas fases del ciclo de vida.
Se deben definir normas para mantener la independencia entre las distintas funciones. Los requisitos
mínimos de seguridad se definen en el capítulo 7 de la Norma EN 50126-2: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-1:2018
- 58 -
Dentro de los límites impuestos por los requisitos para la independencia de las funciones, una persona
puede desempeñar más de una función.
6.5
Aplicación de esta norma y adaptabilidad al campo de aplicación y tamaño del
proyecto
6.5.1
Requisitos generales
Este apartado establece los requisitos para una aplicación flexible y eficaz de esta norma en términos
de tamaño y complejidad.
El proceso de gestión de RAMS descrito en esta norma se basa en el modelo de ciclo de vida aplicado al
sistema en estudio. El alcance de la aplicación de los requisitos definidos en el capítulo 7 al sistema en
estudio se debe definir en el plan de RAMS.
Se debe elegir un modelo de ciclo de vida para el desarrollo del sistema en estudio. El modelo de ciclo
de vida debe tener en cuenta la posibilidad de iteraciones dentro de las fases y entre ellas.
Los siguientes requisitos deben considerarse normativos:
• se deben definir las responsabilidades relativas a la realización de las tareas de RAMS, incluidas las
conexiones entre las tareas asociadas, para el sistema en estudio;
• todo el personal con responsabilidades dentro del proceso de gestión de RAMS debe ser
competente para asumir dichas responsabilidades;
• se deben establecer el plan de RAM y el plan de seguridad.
El sistema de gestión de la calidad debe cumplir con los requisitos de la Norma EN ISO 9001 o
equivalentes y ser apropiado para el sistema en estudio.
NOTA La conformidad con estos requisitos es suficiente para la gestión de la calidad de los requisitos de RAM y constituye
una base necesaria para la gestión de la seguridad que es necesaria para cumplir los requisitos de seguridad.
• se debe utilizar un sistema de gestión de la configuración adecuado que aborde las tareas de RAMS.
El alcance de la gestión de la configuración dependerá del sistema en estudio, pero debe incluir al
menos la documentación del sistema.
La aplicación de esta norma puede adaptarse permitiendo que los requisitos del capítulo 7 se adapten
a los requisitos específicos del sistema en estudio. En dicha adaptación se deberían considerar los
siguientes aspectos:
• las limitaciones impuestas por el responsable del servicio ferroviario;
• la complejidad del sistema en estudio;
• el ámbito de aplicación (es decir, señalización, material rodante, instalaciones fijas);
• el proceso de desarrollo del sistema utilizado;
• el tipo de desarrollo (por ejemplo, producto genérico, aplicación específica, modificación del
sistema existente).
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-1:2018
El proceso puede simplificarse reutilizando la documentación existente aplicable.
EJEMPLO
Un ejemplo de documentación que puede reutilizarse se encuentra en la Especificación Técnica
CLC/TS 50562:2011, Aplicaciones ferroviarias. Instalaciones fijas. Proceso, medidas de protección y
demostración de la seguridad para los sistemas eléctricos de tracción.
Se deben identificar explícitamente todos los requisitos de la norma que el encargado de aplicarla
decida adaptar u omitir.
NOTA La entidad que aplica las normas es responsable de aplicar los requisitos a cada fase del ciclo de vida de la que es
responsable. La responsabilidad del cumplimiento puede surgir por razones como obligaciones contractuales,
obligaciones legales o cuando el usuario de la norma desee reclamar el cumplimiento de la norma. La presentación de
la adaptación propuesta por el usuario de la norma permite llegar a un acuerdo explícito entre comprador y usuario
sobre estos aspectos.
En caso de adaptación, se deben realizar las siguientes especificaciones y justificaciones:
a)
especificar las fases del ciclo de vida que se requieren para realizar el sistema en estudio y
demostrar que las tareas emprendidas en estas fases del ciclo de vida cumplen los principios de
los requisitos de esta norma;
b) especificar las fases del ciclo de vida que no sean necesarias para la realización del sistema en
estudio y justificarlas adecuadamente;
c)
especificar las actividades y los requisitos de cada fase del ciclo de vida requeridos, utilizando la
tabla 1 y la información relacionada con la fase pertinente del capítulo 7, incluyendo:
•
el alcance de cada requisito en relación al sistema en estudio;
•
los métodos, herramientas y técnicas necesarios para cada requisito, así como el ámbito y la
profundidad de su aplicación;
•
las actividades de verificación y validación necesarias para cada requisito y su alcance;
•
toda la documentación justificativa;
d) justificar el límite de aplicabilidad para las tareas y requisitos de la norma.
En la práctica, el sistema en estudio puede ser:
• parte de un sistema más amplio y/o incorporar sistemas más pequeños (subsistemas, productos,
etc.) gestionados con su propio proceso RAMS (véase 6.5.2);
• parte de una renovación, incluyendo o interconectando sistemas existentes, con una posible etapa
de "fase mixta" (véase 6.5.3);
• una reutilización o adaptación de un sistema ya aceptado, incluida la aplicación específica de un
producto genérico/aplicación definidos (véase 6.5.4).
Cuando un sistema incluya un elemento con subsistemas o equipos comerciales (COTS), también
puede ser necesario adaptar el proceso como se describe en 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-1:2018
6.5.2
- 60 -
Caso de sistemas complejos con diferentes niveles jerárquicos
Al definir el ciclo de vida de un determinado sistema en consideración, se debe definir qué sistemas
subordinados (subsistemas/productos) se incorporarán y, en la medida en que se conozca, qué
sistemas superiores han originado requisitos.
La definición del campo de aplicación correspondiente permitirá identificar en el ciclo de vida las fases
que serán total o parcialmente tratadas por el proceso de gestión de RAMS.
Figura 9 – Ejemplo de ciclos de vida en diferentes niveles jerárquicos
NOTA 1 La figura muestra la relación entre el nivel N, es decir, el sistema en estudio del que es responsable la entidad que
aplica la norma, con el nivel superior del sistema N+1 y el nivel de sistema subordinado N-1. La entidad que aplica la
norma para el sistema en estudio es responsable de la integración de los sistemas subordinados. La responsabilidad
de la integración del sistema en estudio en un sistema superior recae en la entidad correspondiente.
NOTA 2 El grado de sombreado de la figura varía desde el color más oscuro (destinado a las tareas de la fase
correspondiente que se espera aplicar completamente) hasta el color más claro (destinado a las tareas de la fase
correspondiente que se espera aplicar parcialmente).
Siempre que el alcance de una fase del ciclo de vida para un sistema en el nivel N pueda afectar al
proceso de gestión de RAMS del sistema en el nivel N+1 o en el nivel N-1, el nivel N debe describir la
relación entre los procesos de gestión de la seguridad relacionados, si se conocen, y si no se conocen,
debe identificar claramente los supuestos relacionados y registrar las limitaciones relacionadas en las
condiciones de aplicación.
EJEMPLO
En la figura 9, las fases 1 a 4 para un sistema subordinado son de color más claro porque se puede
definir una especificación de requisitos y una lista de peligros aplicables para un componente,
independientemente de la definición preventiva de un sistema en un nivel superior. Una vez que los
supuestos estén claramente definidos y documentados, será entonces el sistema superior el que
asegurará las relaciones entre sus requisitos y los peligros aplicables con los del componente
incorporado.
Las suposiciones de RAMS sobre las interfaces se deben indicar y referenciar explícitamente durante la
fase del ciclo de vida de la definición del sistema.
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-1:2018
Las restricciones de RAMS relacionadas con las interfaces introducidas en caso de incorporación de
sistemas nuevos o existentes (subsistemas, productos, etc.) se deben definir y referenciar
explícitamente durante la fase 5 (Arquitectura y asignación de los requisitos del sistema).
El proceso de gestión de RAMS debe especificar cómo se gestionan las condiciones de aplicación
relacionadas con RAMS y se comunican a las partes interesadas pertinentes para su cumplimiento.
Esto incluye:
– condiciones de aplicación exportadas de los sistemas subordinados incorporados (subsistemas,
productos, etc.) durante la fase de integración;
– condiciones de aplicación exportadas a un sistema superior y a otras partes interesadas.
6.5.3
Renovación dentro de los sistemas existentes
El proceso de gestión de RAMS debe considerar los posibles efectos de la interacción entre sistemas
existentes y renovados, incluyendo las hipótesis sobre el rendimiento de la seguridad de los sistemas
existentes.
NOTA En caso de cambios que afecten a sistemas ya aceptados, ha de investigarse el impacto en RAMS de los sistemas
vecinos a través de interfaces y el impacto resultante en RAMS de la explotación del sistema ferroviario. La definición
del sistema determina el esquema de evaluación con la descripción de los límites e interfaces y, dado que el proceso
en sí es adaptable al nivel del sistema, subsistema o producto, la extensión y profundidad del análisis puede ajustarse
a un nivel apropiado para la tarea en cuestión.
Durante la evaluación de riesgos se identifican y valoran los posibles peligros/peligros equivalentes RAM resultantes
del cambio (interfaces incluidos), y se definen los requisitos resultantes y que se asignan en la medida de lo posible.
Después de esto, solo se reconsiderarán las fases afectadas del proceso.
Si el cambio no crea un riesgo adicional (por ejemplo, al crear un nuevo peligro o su equivalente RAM, al hacer que un
peligro existente o su equivalente RAM sea más probable o al cambiar las consecuencias de un peligro o su peligro
equivalente para RAM), se documentará el argumento utilizado.
Los mismos requisitos se aplican a los casos de renovación de un sistema, siempre que haya una "fase
mixta" en la que la explotación con los sistemas existentes y renovados sea mixta, o cuando se exploten
a la vez.
6.5.4
Reutilización o adaptación de un sistema con aceptación previa
En caso de reutilización o adaptación de un sistema con aceptación previa, puede aplicarse un
reconocimiento mutuo (a veces denominado aceptación cruzada) de aceptación previa que limite el
esfuerzo en el ciclo de vida correspondiente. Este caso se considera un caso especial de adaptación.
NOTA 1 Los aspectos legales que implican estos temas quedan fuera del campo de aplicación de esta norma y han de tratarse
teniendo en cuenta el marco legal.
NOTA 2 La adaptación discutida en este apartado tiene el propósito de reutilizar los resultados y documentos existentes que
cumplan con esta norma que hayan sido creados en otros desarrollos y evitar la repetición de procesos/tareas.
Este caso también puede aplicarse a una aplicación específica de un producto/aplicación genérico
definido, como se define en el capítulo 8.
En caso de reutilización o adaptación de un sistema con aceptación previa, deberían tenerse en cuenta
los siguientes principios:
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-1:2018
a)
- 62 -
establecer una argumentación creíble con pruebas de la solicitud de referencia original;
b) especificar el entorno y la aplicación objetivos;
c)
identificar las diferencias entre la aplicación de referencia modificada y la original, incluida la
prueba de que el contexto operativo y de entorno de la nueva aplicación es idéntico/similar al
original y que los requisitos técnicos y relacionados con el proceso siguen siendo adecuados en la
nueva solicitud;
d) especificar las adaptaciones técnicas, de explotación y de procedimiento necesarias para
compensar las diferencias;
e)
evaluar los riesgos derivados de las diferencias;
f)
producir una argumentación creíble con pruebas de las adaptaciones que controlen
adecuadamente los riesgos derivados de las diferencias;
g)
desarrollar una argumentación genérica o específica con pruebas de reconocimiento mutuo.
6.6
Requisitos generales de la documentación de RAMS
Se debe establecer un plan de RAM y un plan de seguridad que identifiquen los documentos que
registran la información relevante para RAMS a lo largo del ciclo de vida del sistema en estudio.
En el Plan de RAM y en el Plan de Seguridad se debe definir o referenciar un proceso para el
mantenimiento de la documentación de RAMS.
Para cada documento, se debe facilitar la trazabilidad mediante un número de referencia único
(incluida la versión) que incluya una relación definida y documentada con otros documentos.
Cada documento y entregable de RAMS debe someterse al control de configuración desde la
publicación de la primera versión.
Se debe registrar cualquier cambio en los documentos sometidos al control de la configuración.
Todos los documentos deben contar con una lista de acrónimos y abreviaturas definidos. Cuando
existan diferencias de significado por razones históricas dentro de un documento determinado, se
deben recoger los diferentes significados y se deben proporcionar las referencias.
Si los documentos de sistemas, productos o procesos preexistentes no cumplen con los requisitos de
este apartado, debe garantizarse que dichos documentos estén adecuadamente vinculados a la nueva
documentación, incluidas las condiciones aplicables. Se deben indicar las posibles contradicciones y, si
procede, se debe indicar el nivel de prioridad de los documentos utilizados.
Los contenidos de todos los documentos deben registrarse de forma apropiada para su manipulación,
tratamiento y almacenamiento.
Los documentos pueden combinarse o dividirse de acuerdo con los requisitos de esta apartado.
Cuando se adopte una estructura alternativa de ciclo de vida o de documentación, se debe comprobar
que cumple todos los objetivos y requisitos de esta norma europea.
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-1:2018
Cuando los documentos producidos por entidades con distintas funciones (como se define en el
apartado 6.4) se combinen en un solo documento, la relación con las partes producidas por entidades
con roles independientes debe trazarse en el seno del documento.
Si los documentos tienen una relación jerárquica:
a)
no debe haber contradicciones con el documento precedente;
b) el documento pertinente debería contener o implementar todas las condiciones y requisitos
aplicables del documento precedente con el que tenga una relación jerárquica.
Siempre que se aplique una cascada de referencias, debería tenerse en cuenta la complejidad creciente
para realizar tareas de verificación y validación.
No es necesario incluir grandes volúmenes de información detallada en los documentos de RAMS,
siempre que se indique la referencia, título, propósito y alcance de los documentos referenciados.
En esta norma, algunos documentos se mencionan varias veces en la descripción del ciclo de vida. Con
ello se pretende destacar que podría ser necesario actualizar el documento en función del resultado de
cada fase del ciclo de vida. No es necesario producir versiones separadas del documento para cada
caso.
6.7
Verificación y validación
6.7.1
Introducción
Esta norma europea aborda las tareas de verificación y validación en el contexto de RAMS. No
obstante, estas tareas deberían formar parte integral de las tareas generales de verificación y
validación del sistema.
6.7.2
Verificación
En esta norma europea, las tareas de verificación se incluyen en cada fase del ciclo de vida. Las tareas
de verificación facilitan y proporcionan entradas de información para la validación.
El objetivo de la verificación es demostrar que se han cumplido los requisitos de cada fase del ciclo de
vida.
En cada fase del ciclo de vida, como se describe en el capítulo 7 de esta norma europea, se debe llevar a
cabo la verificación de las actividades y de los entregables para comprobar el cumplimiento de los
requisitos de la fase del ciclo de vida correspondiente definidos en esta norma europea.
En cada fase del ciclo de vida, las tareas de verificación deben abarcar los siguientes puntos:
a)
la exactitud y adecuación del análisis de RAMS, cuando se especifique;
b) la conformidad de los entregables de la fase correspondiente con los entregables de fases
anteriores;
c)
la adecuación de los métodos, herramientas y técnicas utilizados en la fase del ciclo de vida,
cuando se especifique;
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-1:2018
- 64 -
d) la exactitud, coherencia y adecuación de las especificaciones de ensayo y de los ensayos
realizados, según proceda.
Los errores o deficiencias encontrados pueden requerir la reaplicación de algunas o todas las
actividades de una o más fases anteriores del ciclo de vida.
6.7.3
Validación
Las actividades de validación se llevan a cabo del siguiente modo:
– En la fase 4 del ciclo de vida "Especificación de los requisitos del sistema", la validación tiene como
objetivo garantizar que los requisitos del sistema (incluidos los requisitos de RAMS) se han
especificado correctamente, aplicando los requisitos definidos en esta norma y cualesquiera otros
requisitos específicos adicionales definidos por el marco legal aplicable.
– En la fase 9 del ciclo de vida "Validación del sistema", la validación tiene como objetivo garantizar
que el sistema en estudio cumple los requisitos especificados para el uso o la aplicación previstos.
La validación puede depender adicionalmente de los requisitos específicos definidos por la normativa
legal aplicable.
La responsabilidad de las diferentes actividades de validación depende del marco contractual o legal.
Siempre se deben definir explícitamente las partes interesadas responsables del proceso de validación
a lo largo del ciclo de vida del sistema.
NOTA La validación prevista en la fase 4 del ciclo de vida se encuentra generalmente dentro del ámbito de los responsables
del servicio ferroviario, mientras que la validación prevista en la fase 9 del ciclo de vida puede estar en el ámbito del
fabricante/proveedor.
Los entregables de validación de RAMS deben producirse en la fase 4 del ciclo de vida "Especificación
de requisitos del sistema" y en la fase 9 del ciclo de vida "Validación del sistema". Las entradas de
información para estos entregables deben provenir de tareas realizadas en fases anteriores del ciclo
de vida.
A lo largo del ciclo de vida del sistema en estudio, la entidad de validación implicada debe cumplir los
requisitos de independencia (véase el capítulo 7 de la Norma EN 50126-2:2017).
La validación debe demostrar que el proceso del sistema en estudio, incluida la información generada
correspondiente al ciclo de vida de cada una de las fases del ciclo de vida, son tales que:
– los requisitos de RAMS del sistema en estudio, incluidas las condiciones de aplicación relacionadas
con la seguridad, se han especificado adecuadamente para el uso o la aplicación previstos;
– el sistema en estudio, incluidas las condiciones de aplicación relacionadas con la seguridad, cumple
los requisitos de RAMS correspondientes para el uso o la aplicación previstos.
El alcance de la validación, los objetivos y las actividades se deben especificar en un plan de validació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
- 65 -
UNE-EN 50126-1:2018
La descripción del proceso de gestión de RAMS puede incluirse en el plan de validación o en un plan de
seguridad/RAM específico. En función del resultado de las actividades de evaluación de riesgos y del
proceso de adaptación (véase 6.5), se debe definir y justificar el grado de aplicabilidad del proceso de
gestión de RAMS.
El validador debe tener derecho a solicitar o realizar revisiones, análisis y ensayos.
El Plan de Validación de RAMS debe describir o hacer referencia a:
a)
la planificación de las tareas específicas de validación para cada fase del ciclo de vida, según lo
dispuesto en el capítulo 7;
b) una justificación resumida de la estrategia de validación elegida. La justificación debería incluir:
–
la estrategia seguida en los ensayos,
–
la aceptación de las estrategias de ensayo propuestas por la entidad encargada de realizar los
ensayos,
–
los testigos y cobertura de la estrategia seguida en los ensayos;
c)
los pasos necesarios para demostrar la idoneidad de la especificación del sistema, subsistema,
equipo que ha de validarse, en lo que se refiere al cumplimiento de los requisitos del sistema,
subsistema, equipo. Para el cumplimiento de los requisitos del sistema, subsistema, equipo,
deberían definirse los siguientes puntos:
–
las técnicas y medidas utilizadas,
–
los ensayos y/o análisis utilizados y cómo se comunicarán sus resultados,
–
la gestión de las desviaciones entre los resultados previstos y los resultados reales de los ensayos
y/o análisis,
–
la gestión de las no conformidades y las limitaciones en la seguridad derivadas de las
desviaciones,
–
la gestión de las condiciones y limitaciones derivadas de las desviaciones, y cómo se abordarán en
las próximas tareas del ciclo de vida en lo que se refiere a su impacto en las futuras tareas del ciclo
de vida y su trazabilidad respecto a las desviaciones;
d) los pasos necesarios para demostrar la idoneidad de los ensayos y/o análisis como conjunto
completo de ensayos y/o análisis con los que pueda demostrarse el cumplimiento de los
requisitos relativos a un sistema/subsistema y/o componente. Se deben identificar los
incumplimientos y las desviaciones.
6.8
Evaluación independiente de la seguridad
6.8.1
Objetivos
Una evaluación independiente de la seguridad es un medio importante para proporcionar confianza
adicional en relación a la prevención de fallos sistemáticos del sistema en estudio que puedan afectar
negativamente a la seguridad.
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-1:2018
- 66 -
La evaluación independiente de la seguridad incluye una evaluación y dictamen de que se han
emprendido adecuadamente aspectos específicos del proceso de gestión de la seguridad y/o se han
cumplido los requisitos específicos con respecto al sistema o parte del sistema.
La evaluación independiente de la seguridad también se basa en la evaluación de la verificación y
validación ya realizada. Esta norma no define en qué casos se requiere una evaluación independiente
de la seguridad.
Esta norma define los objetivos y los requisitos aplicables si se realiza una evaluación independiente
de la seguridad.
NOTA 1 La evaluación independiente de la seguridad puede solicitarse y detallarse según normas sobre tecnologías o
sectores específicas, o bien puede ser un requisito contractual.
NOTA 2 El marco legal también puede exigir una evaluación independiente de la seguridad.
6.8.2
Actividades
El contenido y el alcance de todas las actividades de evaluación independiente de la seguridad se
deben describir en un plan para la evaluación independiente de la seguridad elaborado por las
entidades responsables de la evaluación en cooperación con el solicitante y se deben basar en la
definición del sistema y en la especificación de los requisitos del sistema/subsistema y/o de los
componentes. Este plan debe incluir:
• alcance (objetivo y campo de aplicación) de las actividades de evaluación independiente de la
seguridad;
• el detalle de las actividades a lo largo del proceso de evaluación independiente de la seguridad y su
relación con las actividades técnicas o de explotación;
• los elementos de desarrollo (incluidos los documentos) que han de tenerse en cuenta;
• las declaraciones de aceptación/rechazo y la forma de tratar los casos de no conformidad;
• los requisitos relativos al contenido y la forma de la documentación de la evaluación independiente
de la seguridad.
Cada evaluación independiente de la seguridad debe:
• cumplir con el plan de evaluación independiente de la seguridad;
• establecer un entendimiento del proceso o sistema, subsistema, equipo dentro del entorno
definido;
• evaluar la idoneidad y exhaustividad del plan de validación de RAMS con respecto a la seguridad;
• evaluar la conformidad del proceso y los resultados desarrollados de acuerdo con los requisitos y
actividades definidos en esta norma europea, teniendo en cuenta también la verificación y
validación ya realizadas;
• identificar y evaluar cualquier desviación de los requisitos establecidos en la evaluación
independiente 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
- 67 -
UNE-EN 50126-1:2018
• emitir un juicio sobre la aceptabilidad de la justificación de la seguridad (incluidas las desviaciones)
dada por el proyecto en el caso de seguridad descrito en el capítulo 8. Esto incluye la comprobación
de que las limitaciones pertinentes se tienen en cuenta en condiciones de aplicación relacionadas
con la seguridad y son suficientes para controlar los riesgos;
• llevar a cabo inspecciones sobre el proceso global de desarrollo del sistema, según proceda, en las
distintas fases de desarrollo, y posibilitar la solicitud de tareas adicionales de verificación y
validación en el marco de la evaluación independiente de la seguridad;
• facilitar registros de las actividades de evaluación independiente de la seguridad.
Para el cumplimiento de estos puntos, la entidad que lleve a cabo la evaluación independiente de la
seguridad debe tener acceso al proceso de desarrollo del sistema y a toda la documentación
relacionada con el proyecto.
El informe de evaluación independiente de la seguridad:
• debe identificar todos los elementos evaluados del sistema en estudio;
• debe registrar los resultados de la evaluación independiente de la seguridad;
• debe aportar una conclusión;
• puede aportar recomendaciones.
Un sistema/subsistema y/o componente que ya contara con una evaluación independiente de la
seguridad debe evaluarse para su integración segura en el nuevo sistema en funcionamiento en
consideración y en su entorno correspondiente.
La entidad que vaya a realizar la evaluación independiente de la seguridad debe cumplir los requisitos
definidos en el capítulo 7 de la norma EN 50126-2:2017.
NOTA El marco legal puede imponer requisitos adicionales para una evaluación independiente (por ejemplo, cumplir con los
requisitos de la Norma EN ISO/IEC 17020).
En caso de que el marco legal requiera otros tipos de evaluaciones de la seguridad basadas en
regulaciones específicas para su autorización, pueden combinarse con la evaluación independiente de
la seguridad especificada en esta norma, asignando evaluadores cualificados.
Los documentos existentes (es decir, los planes genéricos de evaluación independiente de la
seguridad) o los procedimientos existentes pueden reutilizarse si se ajustan a los requisitos del
sistema en estudio.
La evaluación independiente de la seguridad debe producir los siguientes entregables principales:
– plan de evaluación independiente de la seguridad;
– registro de los resultados de la evaluación independiente de la seguridad;
– informe de la evaluación independiente de la seguridad.
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-1:2018
- 68 -
7 Ciclo de vida de RAMS
7.1
Generalidades
Este apartado detalla los objetivos, requisitos y entregables para las actividades de RAMS que se
llevarán a cabo durante cada fase del ciclo de vida.
NOTA 1 Las fases del ciclo de vida se introducen y explican en el apartado 6.1.
NOTA 2 Los requisitos generales para la verificación y validación figuran en el apartado 6.7.
NOTA 3 Los requisitos para las actividades de evaluación independiente de la seguridad figuran en el apartado 6.8.
NOTA 4 En otras normas (véase el capítulo A.4) se presentan ejemplos de métodos, herramientas y técnicas apropiadas para
los sistemas fiables de ingeniería de RAMS.
NOTA 5 Los requisitos relativos a la adaptación del campo de aplicación y la aplicabilidad de los requisitos (adaptación) para
satisfacer las necesidades particulares del sistema en estudio figuran en el apartado 6.4. El ciclo de vida puede
simplificarse (mediante su adaptación) ya que se pueden reutilizar procesos y documentos y las actividades pueden
centrarse en las desviaciones con respecto al sistema original.
En caso de rediseño, reajuste o modificación, se debe identificar cualquier impacto en la fiabilidad,
disponibilidad, mantenibilidad y seguridad. Se debe realizar un análisis de impacto para decidir cómo
ha de adaptarse el ciclo de vida.
7.2
Fase 1: Concepto
7.2.1
Objetivos
El objetivo de esta fase es desarrollar una comprensión suficiente del sistema para garantizar un
rendimiento adecuado de todas las actividades del ciclo de vida de RAMS posteriores.
7.2.2
Actividades
En el contexto del rendimiento de RAMS, deberían analizarse los siguientes aspectos:
a)
el campo de aplicación, contexto y propósito del sistema;
b) el entorno del sistema, incluyendo:
–
cuestiones físicas,
–
cuestiones con la interfaz del sistema,
–
cuestiones legislativas y económicas (si pueden tener impacto);
c)
los requisitos previos de RAMS y el rendimiento de RAMS en el pasado de sistemas similares y/o
relacionados;
d) la política y los objetivos actuales de RAMS de los responsables del servicio ferroviario
correspondientes;
e)
la legislación en materia 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
- 69 -
UNE-EN 50126-1:2018
Se debe definir el campo de aplicación de los requisitos de gestión de RAMS para las siguientes tareas
de RAMS del ciclo de vida del sistema.
7.2.3
Entregables
Los resultados de las actividades de esta fase del ciclo de vida deben documentarse y se deben incluir
todas las hipótesis y justificaciones formuladas durante esta fase del ciclo de vida.
7.3
Fase 2: Definición del sistema y contexto operativo
7.3.1
Objetivos
Los objetivos de esta fase del ciclo de vida son:
a)
definir el sistema y el perfil de su misión;
b) definir las fronteras del sistema;
c)
establecer los requisitos de explotación que influyen en las características del sistema;
d) definir el campo de aplicación del análisis de riesgos del sistema;
e)
establecer el plan de RAM inicial para el sistema;
f)
establecer el plan de seguridad inicial para el sistema;
g)
definir las funciones que ha de proporcionar el sistema;
h) definir la organización para la gestión de RAM y de la seguridad del sistema
en la medida en que afecten al rendimiento potencial de RAMS del sistema.
En el anexo D de esta norma europea se ofrecen directrices generales para la definición del sistema.
7.3.2
Actividades
7.3.2.1
Generalidades
Antes de realizar cualquier análisis relacionado con RAMS (por ejemplo, identificación de peligros), se
deben establecer las fronteras y funciones del sistema en estudio. Por tanto, deben tener en cuenta al
menos las siguientes cuestiones:
a)
el objetivo del sistema (propósito previsto) y el perfil de su misión, incluyendo:
–
la descripción del sistema en estudio, incluidas las funciones del sistema y los elementos que han
de incluirse, y las funciones del sistema que han de excluirse en el análisis,
–
la estrategia y condiciones de explotación a largo plazo,
–
la estrategia y condiciones de mantenimiento a largo plazo,
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-1:2018
- 70 -
–
las consideraciones sobre la vida útil del sistema,
–
las consideraciones logísticas;
b) las fronteras del sistema, incluyendo:
–
las interfaces e interacciones con el entorno físico (por ejemplo, condiciones climáticas,
condiciones mecánicas, altitud) y con otros sistemas,
–
las interfaces e interacciones con otros sistemas tecnológicos,
–
las interfaces e interacciones con humanos,
–
las interfaces e interacciones con otros responsables del servicio ferroviario.
Además de las interfaces funcionales, la ubicación o ubicaciones de las partes del sistema y sus
interfaces pueden influir en los sistemas y entornos vecinos.
c)
el campo de aplicación de los requisitos de explotación que influyen en el sistema, incluyendo:
–
las limitaciones impuestas por la infraestructura existente,
–
las condiciones y limitaciones de explotación del sistema,
–
las condiciones de mantenimiento del sistema,
–
las consideraciones de apoyo logístico,
–
la revisión de los datos de experiencias pasadas para sistemas similares,
–
la influencia en el personal de explotación y mantenimiento, pasajeros y público, o cómo se
previene dicha influencia,
–
la descripción de los procedimientos de explotación, la identificación del personal autorizado para
llevar a cabo estas acciones y la indicación de sus competencias, cualificaciones así como los
recursos temporales necesarios, si forman parte de las condiciones y limitaciones de explotación
del sistema,
–
si no se han incluido actividades humanas en el análisis, deberían indicarse las razones,
–
los diferentes modos de explotación (es decir, normal, anormal/degradado, modo de
mantenimiento), estados y transiciones y sus interacciones, si pueden tener un impacto en la
funcionalidad y seguridad de los sistemas;
d) las medidas de seguridad existentes y las hipótesis que determinan los límites para la evaluación
de riesgos;
e)
la identificación del sistema y de los documentos relacionados, incluidas las suposiciones
realizadas sobre determinadas funciones o subsistemas que difieren de una versión de referencia
existente, indicando y justificando explícitamente las desviaciones.
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-1:2018
Para los elementos relacionados con el software está claro que el software no puede estudiarse de
forma individual. Sólo teniendo en cuenta el software cargado en un sistema que opera dentro de un
determinado entorno y cumple una determinada función es viable proporcionar una definición
completa del sistema.
Se debe establecer una política de RAMS que incluya una política para resolver conflictos entre
seguridad y otros aspectos como disponibilidad, fiabilidad, etc.
Debe crearse una organización que asigne las funciones, responsabilidades, competencias,
independencia y gestione las relaciones entre las organizaciones que realicen tareas de RAMS en el
proceso del ciclo de vida. Esto debe servir también para resolver los conflictos indicados
anteriormente.
Debería establecerse un proceso para el examen continuo de las cuestiones de seguridad y la
comunicación de los requisitos pertinentes de seguridad del sistema entre las partes interesadas. Esto
incluye la revisión de la adecuación de los requisitos de seguridad si se producen nuevos hallazgos que
requieran reconsiderar determinados aspectos.
7.3.2.2
Plan de RAM
El plan de RAM para las tareas restantes del ciclo de vida debe establecerse, revisarse y mantenerse
durante todo el ciclo de vida del sistema. El plan de RAM debe incluir las tareas que se consideren más
eficaces para cumplir los requisitos de RAM del sistema en estudio. El responsable del servicio
ferroviario y los proveedores ferroviarios deberían acordar el plan de RAM para el sistema en estudio.
NOTA Se puede realizar un análisis preliminar de RAM para determinar los objetivos. Esto se recomienda al menos en
proyectos de alto riesgo.
El plan de RAM debe definir las disposiciones de gestión que ayuden a cumplir los requisitos de RAM.
Esto incluye detalles de la política y estrategia a aplicar, el campo de aplicación y la planificación de las
actividades de RAM.
El plan de RAM debe incluir lo siguiente:
a)
La gestión, incluidos los detalles de:
–
el ciclo de vida del sistema y las tareas y procesos de RAM a realizar dentro del ciclo de vida;
–
un Sistema de Comunicación de Fallos y Medidas Correctivas (FRACAS) que se ha de aplicar al
sistema en estudio a partir de la fase 7 del ciclo de vida (por el responsable del servicio ferroviario
y/o por los proveedores ferroviarios, según proceda y de común acuerdo entre las partes
interesadas) con registros que incluyan, por ejemplo:
• datos técnicos del sistema,
• acciones de mantenimiento,
• informes y medidas correctivas;
–
todos los entregables relacionados con RAM 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-1:2018
- 72 -
–
tareas para la aceptación de RAM;
–
las limitaciones y suposiciones establecidas en el plan de RAM;
–
disposiciones para la gestión de subcontratistas.
b) La fiabilidad, incluyendo:
–
el análisis y la predicción de la fiabilidad;
–
la planificación de la fiabilidad;
–
los ensayos de fiabilidad;
–
la adquisición y la evaluación de datos de fiabilidad.
c)
la disponibilidad, incluyendo
–
el análisis de disponibilidad;
–
el análisis de sensibilidad;
–
la adquisición y evaluación de los datos de disponibilidad.
d) La mantenibilidad, incluyendo
–
el análisis y la predicción de la mantenibilidad;
–
la planificación de la mantenibilidad;
–
la evaluación del apoyo logístico.
El plan de RAM se considera un documento vivo. Si algún contenido de la lista anterior no está
completamente disponible en esta fase inicial del ciclo de vida, puede añadirse en fases posteriores del
ciclo de vida.
7.3.2.3
Plan de seguridad
Se debe establecer el plan de seguridad para el sistema. El plan de seguridad se debe implementar,
revisar y mantener durante todo el ciclo de vida del sistema. Por tanto, es necesario definir la relación
entre las partes interesadas involucradas.
El plan de seguridad debe definir las siguientes actividades de seguridad:
a)
la política y la estrategia para lograr la seguridad;
b) el campo de aplicación del plan;
c)
la planificación de las actividades 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
- 73 -
UNE-EN 50126-1:2018
d) el ciclo de vida del sistema subyacente, así como el análisis de seguridad, los procesos de
ingeniería y la relación con la evaluación que ha de aplicarse durante el ciclo de vida, incluidos los
procesos para:
–
garantizar un grado adecuado de independencia del personal en las tareas, proporcional a los
riesgos del sistema,
–
la identificación y el análisis de peligros,
–
la evaluación de riesgos y la gestión continua de riesgos,
–
los criterios de aceptación de riesgos y la revisión de la aceptación de riesgos,
–
examinar la eficacia de las medidas de reducción de riesgos,
–
el establecimiento y la revisión continua de la adecuación de los requisitos de seguridad,
–
el diseño del sistema,
–
la verificación,
–
la validación para lograr la conformidad entre los requisitos del sistema y su realización,
–
la demostración de la conformidad del proceso de gestión con el plan de seguridad (por ejemplo,
confirmado mediante auditorías),
–
la garantía de seguridad durante la parametrización del sistema (clasificación de seguridad de los
parámetros de configuración, confianza en la seguridad del proceso de parametrización y
herramientas utilizadas);
e)
detalles de todos los entregables relacionados con la seguridad de las fases del ciclo de vida,
incluidos los siguientes:
–
documentación,
–
hardware,
–
software;
f)
un proceso para preparar el caso de seguridad, teniendo en cuenta la jerarquía entre las
actividades de seguridad del sistema y la documentación;
g)
un proceso para la aprobación de la seguridad del sistema, incluida la interfaz con el responsable
del servicio ferroviario y la autoridad responsable de la seguridad;
h) un proceso para analizar el rendimiento del mantenimiento y la explotación a fin de garantizar
que la seguridad no se vea comprometida por desviaciones en la explotación y el mantenimiento
asumidos;
i)
un proceso para el mantenimiento de la documentación relacionada 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-1:2018
- 74 -
j)
un proceso para la gestión del registro de peligros;
k)
interfaces con otros programas y planes relacionados;
l)
limitaciones e hipótesis establecidas en el plan;
m) disposiciones para la gestión de subcontratistas;
n) auditorías de seguridad, evaluaciones de seguridad y revisiones de seguridad periódicas a lo largo
del ciclo de vida y adecuadas a la relevancia para la seguridad del sistema en estudio, incluidos los
requisitos de independencia del personal.
El plan de seguridad se considera un documento vivo. Si algún contenido de la lista anterior no está
completamente disponible en esta fase inicial del ciclo de vida o si cambia en una fase posterior del
ciclo de vida, la información puede añadirse en fases posteriores del ciclo de vida.
NOTA El anexo A de esta norma proporciona un ejemplo de procedimiento resumido para la definición de un plan de
RAM/plan de seguridad, basado en los requisitos de esta norma. El Anexo A es informativo y orientativo, y se ha
completado utilizando como ejemplo el sistema de material rodante.
7.3.3
Entregables
Se deben documentar los resultados de esta fase del ciclo de vida, incluyendo
a)
una definición del sistema;
b) un plan de RAM;
c)
un plan de seguridad.
Esta documentación debe incluir todas las hipótesis y justificaciones formuladas durante esta fase del
ciclo de vida.
7.4
Fase 3: Análisis y valoración de riesgos
7.4.1
Objetivos
Los objetivos de esta fase del ciclo de vida son los siguientes:
a)
identificar y clasificar los peligros/peligros equivalentes RAM asociados al sistema;
b) seleccionar los principios de aceptación de riesgos (RAP);
c)
definir y aplicar los criterios de aceptación de riesgos (RAC);
d) evaluar los riesgos;
e)
establecer un proceso para la gestión continua de riesgos.
NOTA Los peligros equivalentes RAM son condiciones que podrían ocasionar pérdidas económicas relacionadas con RAM.
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-1:2018
Por cuestiones de simplificación, la representación del ciclo de vida en esta norma muestra el análisis
de riesgos como una actividad puntual en la fase inicial de un proyecto. En esta fase, para algunos
aspectos del análisis de riesgos solo se pueden hacer estimaciones porque el diseño detallado del
producto, sistema o proceso aún no está disponible y no se ha analizado. Este análisis de riesgo
temprano sirve como base para definir los requisitos RAMS del sistema basados en riesgos (véase la
fase 4 del ciclo de vida en el apartado 7.5).
Posteriormente, se debe llevar a cabo una gestión continua de los riesgos con el fin de garantizar que
se controlan los riesgos asociados al sistema, subsistema y equipo.
Todo análisis que se realice durante el proceso debería incluir o hacer referencia a:
1) los límites de todo análisis realizado;
2) las hipótesis realizadas durante el análisis;
3) los límites de confianza aplicables a los datos utilizados en el análisis;
4) los métodos, herramientas y técnicas utilizadas.
7.4.2
Actividades
7.4.2.1
Evaluación de riesgos
La evaluación de riesgos para el sistema en estudio incluye también la fase de definición del sistema
(fase 2 del ciclo de vida) y debe realizarse de acuerdo con los requisitos establecidos en el apartado
6.3. La evaluación de riesgos comprende el análisis y la valoración de riesgos.
El análisis de riesgos, utilizando enfoques cualitativos, cuantitativos o híbridos, es un proceso
sistemático y estructurado para:
1.
Identificar las incidencias no deseadas que puedan ocasionar directa o indirectamente pérdidas
durante la explotación y mantenimiento de un sistema. En el contexto de las operaciones
ferroviarias, las pérdidas podrían significar daños a los pasajeros, trabajadores o miembros de la
sociedad, daños al medio ambiente o pérdidas comerciales relacionadas con RAM.
2.
Identificar las causas, por ejemplo, los fallos de componentes, subsistemas o sistemas, los efectos
físicos, que, tal vez combinados con errores humanos o condiciones de explotación, pueden dar
lugar a pérdidas.
3.
Identificar las medidas de control establecidas para controlar o limitar la ocurrencia de cada
evento no deseado cuyo riesgo asociado no sea aceptable.
4.
En caso de una estimación explícita de los riesgos, estimar las frecuencias con las que pueden
ocurrir incidentes no deseados y estimar las consecuencias que pueden tener para los diferentes
resultados que pueden seguir a la ocurrencia de una pérdida. Esto incluiría identificar cuándo es
necesaria una reducción de los riesgos y qué medidas de control se deben aplicar para controlar o
limitar:
–
la frecuencia de ocurrencia de la incidencia no deseada después de la identificación de las causas y
de la incidencia desencadenante;
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-1:2018
- 76 -
y
–
las consecuencias de las pérdidas relacionadas.
Si es factible y viable, el mejor enfoque para controlar un riesgo es su eliminación. Sin embargo, a
menudo no es posible conseguirlo y se aplica la reducción de la frecuencia de incidencias no
deseadas o sus consecuencias. En la figura 10 se muestra un ejemplo relacionado con la seguridad
de la relación entre causa, peligro y accidente. Se puede adaptar a los aspectos de RAM de la
misma manera.
5.
Determinar las medidas adicionales a aplicar que sean necesarias para asegurar que el riesgo se
mitiga a los niveles aceptados dentro del marco legal aplicable por parte de la entidad aplicable
(por ejemplo, satisfacer los criterios definidos de aceptación de riesgos o los requisitos legales).
6.
Proporcionar pruebas documentales claras y exhaustivas de las metodologías, hipótesis, datos,
juicios e interpretaciones utilizadas para llevar a cabo el análisis de riesgos.
Figura 10 – Relación entre causa, peligro y accidente
Es importante señalar que los objetivos de seguridad determinados referentes a categorías de
frecuencia deberían estar relacionados con el elemento en consideración (por ejemplo, una instancia
de la función o del sistema en estudio), pero no con la suma de los elementos en uso o que se pretende
utilizar. En otras palabras, no al conjunto de ellos, sino a la única instancia de esta función o sistema.
De lo contrario, la conformidad con un objetivo de seguridad podría requerir la revisión de un sistema
en caso de que se pongan en servicio equipos idénticos adicionales.
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-1:2018
EJEMPLO 1 Podrían aplicarse las categorías de frecuencia a:
– un sistema de puertas (por puerta);
– un sistema de frenos (por cada unidad de frenado independiente);
– una única señal;
– un conmutador principal en una estación de alimentación.
Sin embargo, es importante tener en cuenta que puede haber diferentes consecuencias cuando se
pierde un solo sistema, o múltiples instancias del mismo sistema. En tal caso, se han de especificar los
requisitos de seguridad del sistema para todas las situaciones de accidente.
EJEMPLO 2 La apertura de una sola puerta cuando el tren está en marcha podría provocar una víctima.
EJEMPLO 3 La apertura de todas las puertas cuando el tren está en marcha podría, sin embargo, provocar
múltiples víctimas mortales. Esto significa que la función de control y mando general podría tener
un objetivo de seguridad más estricto que la función local.
Deben identificarse sistemáticamente todos los peligros/peligros equivalentes RAM razonablemente
previsibles asociados al sistema en su entorno de aplicación. Esta actividad debería incluir los peligros
y los peligros equivalentes RAM derivados de:
a)
la explotación normal del sistema;
b) las condiciones de avería del sistema;
c)
la explotación en modo seguro del sistema;
d) el uso indebido previsible del sistema, excluido el uso indebido deliberado;
e)
las interfaces de sistema;
f)
la funcionalidad del sistema;
g)
los parámetros de configuración del sistema;
h) las cuestiones de explotación, mantenimiento y soporte del sistema;
i)
las consideraciones relativas a la retirada del sistema;
j)
los factores humanos;
k)
las cuestiones de salud ocupacional;
l)
el entorno mecánico;
m) el entorno eléctrico;
n) el entorno natural, para cubrir situaciones como nieve, inundaciones, tormentas, lluvias,
deslizamientos de tierra, 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
UNE-EN 50126-1:2018
- 78 -
Para la identificación de peligros/peligros equivalentes RAM es beneficioso utilizar una lista
estructurada. Dicha lista ha de servir de base aunque no sea exhaustiva. Si se utiliza, debería
comprobarse su validez para la aplicación y modificarse si es necesario.
Se deben definir las relaciones de los peligros/peligros equivalentes RAM con sus consecuencias
relacionadas, identificando la combinación y secuencia de las incidencias desencadenantes.
Los peligros identificados se deben clasificar teniendo en cuenta el dictamen de los expertos, al menos
en aquellos casos asociados con riesgos aceptables en términos generales y en aquellos casos
asociados con riesgos que no se consideren aceptables en términos generales. La Norma EN 50126-2
recoge más información sobre los dictámenes de los expertos.
Los peligros asociados con los riesgos aceptados en términos generales no han de analizarse de forma
exhaustiva pero deben registrarse en el registro de peligros.
NOTA Para obtener más información sobre el criterio "aceptable en términos generales", se aconseja consultar el
apartado 6.3.
Se debe elegir el principio de aceptación de riesgos que se aplicará:
• utilización de códigos de buenas prácticas;
• uso de un sistema similar como referencia;
• estimación explícita del riesgo (cualitativa o cuantitativa).
En caso de elegir la estimación explícita del riesgo, se deben definir los criterios de aceptación del
riesgo.
En la Norma EN 50126-2 figuran detalles sobre el uso de los principios de aceptación de riesgos.
El riesgo para el sistema de cada peligro/peligro equivalente RAM se debe valorar con arreglo a los
criterios de valoración y aceptación de riesgos previamente definidos.
Dependiendo del principio de aceptación de riesgos elegido, puede ser necesario estimar el impacto de
diferentes casos (incluidas las distintas incidencias desencadenantes) para ayudar a formar la decisión
sobre la aceptabilidad de riesgos durante la valoración de riesgos.
7.4.2.2
Registro de peligros
Se debe establecer un registro de peligros como base para la gestión continua de los riesgos en materia
de seguridad. Representa una herramienta para poder realizar la trazabilidad de los peligros y su
cierre. El registro de peligros debe actualizarse a lo largo del ciclo de vida siempre que se produzca un
cambio en los peligros identificados o se identifique un nuevo peligro. El registro de peligros debe
incluir o hacer referencia a detalles de:
a)
el propósito del registro de peligros;
b) cada peligro, las entidades encargadas de su gestión y las funciones o componentes que
contribuyen a dicha gestió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
- 79 -
c)
UNE-EN 50126-1:2018
las consecuencias probables y las frecuencias de la secuencia de incidencias asociadas a cada
peligro, cuando proceda;
d) el riesgo derivado de cada peligro (en términos cuantitativos o cualitativos), cuando proceda;
e)
los principios de aceptación de riesgos seleccionados y, en caso de optar por la estimación
explícita de riesgos, los criterios de aceptación de riesgos para demostrar la aceptabilidad del
control de riesgos relacionado con los peligros;
f)
para cada peligro: las medidas adoptadas para reducir los riesgos a un nivel aceptable o para
eliminarlos;
g)
condiciones de seguridad exportadas.
Pueden existir varios tipos de registros de peligros; por ejemplo, registros internos (para gestionar los
procesos internos de una empresa) y externos, denominados registros de peligros externos. Un
registro de peligros externos es un extracto del registro de peligros que es adecuado para transferir
información entre las partes interesadas. Su objetivo es informar a otras partes interesadas sobre los
aspectos de seguridad pertinentes en las interfaces con sus sistemas o subsistemas y sobre los peligros
que no pueden ser controlados por una sola parte interesada.
NOTA El registro de peligros externos también se puede denominar "archivo de peligros".
7.4.3
Entregables
Se deben documentar los resultados de esta fase del ciclo de vida, incluyendo:
a)
la evaluación de riesgos;
b) el registro de peligros;
c)
el plan de seguridad actualizado (si procede);
d) el plan de RAM actualizado (si procede);
e)
el establecimiento de un plan de evaluación de la seguridad independiente (si procede).
Esta documentación debe incluir todas las hipótesis y justificaciones formuladas durante esta fase del
ciclo de vida.
7.5
Fase 4: Especificación de los requisitos del sistema
7.5.1
Objetivos
Los objetivos de esta fase del ciclo de vida son los siguientes:
a)
especificar el conjunto de requisitos de RAMS para el sistema en estudio;
b) especificar el proceso general de demostración y los criterios para la aceptación de RAMS del
sistema;
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-1:2018
c)
- 80 -
proporcionar un conjunto completo e identificado de requisitos para las siguientes fases del ciclo
de vida;
d) especificar los requisitos de control necesarios según el proceso para el análisis del rendimiento
de la explotación y del mantenimiento previsto en el Plan de Seguridad (que permitan al sistema
realizar las tareas requeridas en la fase 11 del ciclo de vida).
7.5.2
Actividades
El conjunto de requisitos de RAMS para el sistema debe especificarse en base a la definición de sistema
del apartado 7.3 y de análisis y valoración de riesgos del apartado 7.4. Los requisitos de RAMS para el
sistema en estudio deben incluir:
a)
los requisitos funcionales y los requisitos de rendimiento, incluidos los requisitos funcionales de
seguridad y el objetivo de seguridad asociado para cada función relacionada con la seguridad;
b) requisitos de apoyo logístico;
c)
interfaces;
d) entorno de aplicación y perfil de la misión;
e)
niveles de riesgo tolerables para las consecuencias derivadas de los peligros identificados, cuando
proceda;
f)
medidas externas necesarias para cumplir los requisitos;
g)
requisitos de soporte del sistema;
h) detalles de los límites del análisis;
i)
detalles de cualquier hipótesis realizada;
j)
identificación de normas relacionadas con la tecnología;
k)
campo de aplicación del diagnóstico y control y, en particular, los requisitos específicos para el
control de la eficacia de las medidas de seguridad propuestas.
Los requisitos deben expresarse y estructurarse de manera que:
l)
sean completos, precisos, inequívocos, verificables, se puedan someter a ensayo y se puedan
mantener;
m) estén escritos para facilitar la comprensión por parte de quienes puedan utilizar la información en
cualquier fase del ciclo de vida del sistema;
n) se expresen en lenguaje natural o formal y/o en diagramas lógicos, de secuencias o de causa y
efecto. Los requisitos deberían definir las funciones necesarias, definiendo cada función de forma
individual;
o)
el conjunto definido de requisitos sea adecuado para definir un sistema que sea apto para el fin
previsto.
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-1:2018
Se debe especificar el conjunto de requisitos para lograr el cumplimiento de los requisitos de RAMS del
sistema, incluidos los siguientes:
p) criterios de aceptación del conjunto de requisitos de RAMS;
q) un proceso de demostración y aceptación del conjunto de requisitos de RAMS respaldado por el
plan de validación de RAMS del sistema.
NOTA En la Norma EN 50126-2 pueden encontrarse directrices generales sobre la especificación de los requisitos del
sistema de seguridad del sistema.
El plan de seguridad y el plan de RAM se deben actualizar (si procede) para garantizar que todas las
tareas planificadas son coherentes con los requisitos de RAMS emergentes del sistema.
Cuando sea necesario, las hipótesis en las que se apoye la definición de los requisitos de seguridad
deben identificarse como condiciones de aplicación relacionadas con la seguridad para las tareas
futuras del ciclo de vida de explotación, mantenimiento y retirada del servicio.
7.5.3
Entregables
Se deben documentar los resultados de esta fase del ciclo de vida, incluyendo:
a)
especificación de requisitos de RAMS del sistema;
b) condiciones de aplicación relacionadas con la seguridad (si procede);
c)
un registro de peligros actualizado (si procede);
d) plan de seguridad actualizado (si procede);
e)
plan de RAM actualizado (si procede);
f)
el Informe de Validación que cubra las fases 1 a 4;
g)
el plan de validación de RAM para las fases siguientes;
h) el plan de validación de la seguridad para las fases siguientes.
Esta documentación debe incluir todas las hipótesis y justificaciones pertinentes formuladas durante
esta fase del ciclo de vida.
7.5.4
Tareas específicas de validación
Los requisitos generales para las tareas de validación se describen en el apartado 6.7.3.
En esta fase del ciclo de vida se debe establecer un Informe de Validación que incluya:
a)
identificación y nombre de:
–
el sistema en estudio,
–
los documentos y otros elementos utilizados para la validació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-1:2018
- 82 -
–
los procesos, herramientas de soporte técnico y equipos utilizados, si procede,
–
los modelos de simulación utilizados, si procede;
b) confirmación de que el proceso y las actividades se han llevado a cabo de acuerdo con lo descrito
en el plan de seguridad. Deben registrarse y justificarse las desviaciones con respecto al plan de
seguridad;
c)
validación de los requisitos de seguridad del sistema con respecto a los procesos de evaluación de
riesgos realizados hasta el final de la fase 3 del ciclo de vida, véase el apartado 7.4;
d) validación de los requisitos de RAM del sistema con respecto a los objetivos RAM especificados y
las políticas de RAM de los responsables del servicio ferroviario;
e)
confirmación de que todos los requisitos del sistema (incluidos RAMS, requisitos funcionales y
requisitos legales externos) se han analizado y especificado adecuadamente para permitir que el
sistema en estudio sirva a su uso previsto.
En esta fase del ciclo de vida, se debe establecer un Plan de Validación para el cumplimiento de los
requisitos RAMS especificados para el sistema en estudio.
7.6
Fase 5: Arquitectura y asignación de los requisitos del sistema
7.6.1
Objetivos
Los objetivos de esta fase del ciclo de vida son los siguientes:
a)
asignar los requisitos de RAMS del sistema a los subsistemas y/o componentes designados;
b) diseñar subsistemas y componentes que funcionen conjuntamente como un sistema que cumpla
las funciones requeridas a nivel de sistema;
c)
describir los requisitos de RAMS y especificar las interfaces para todos los subsistemas y
componentes derivados de los requisitos de RAMS (que prepara las actividades de integración
posteriores);
d) definir los criterios de aceptación para demostrar el cumplimiento de los requisitos de RAMS para
el sistema, subsistema y equipo en las siguientes fases del ciclo de vida;
e)
identificar y evaluar la importancia de las interacciones entre los subsistemas.
NOTA Las interacciones pueden definirse en diferentes niveles de abstracción. Dichas interacciones pueden describirse en
las especificaciones de interfaz.
7.6.2
Actividades
Se debe desarrollar y definir una arquitectura del sistema que cumpla los requisitos de RAMS. La
arquitectura se debe basar en una descomposición estructurada en subsistemas y/o componentes con
interfaces completamente definidas entre los subsistemas y/o componentes. Para cada subsistema o
componente se debe asignar un conjunto de requisitos de RAMS que se derive de los requisitos del
sistema y del diseño con la profundidad suficiente. Para ello, se debe aplicar una metodología de
diseño estructurada.
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 -
UNE-EN 50126-1:2018
La arquitectura del sistema debería expresarse y estructurarse de manera que sea clara, precisa,
inequívoca, verificable, que se pueda someter a ensayo, que se pueda mantener y sea viable. Debería
ayudar a la comprensión por parte de aquellos que puedan utilizar la información en cualquier fase del
ciclo de vida y ser trazable para los requisitos del sistema.
Se requiere prestar atención especial a la especificación de los requisitos de RAMS para el control de
interfaces en los casos en los que la interacción segura y fiable puede verse comprometida. Se deben
determinar las limitaciones en la elección de la tecnología (es decir, la independencia de las funciones
o los procesos de desarrollo). Se deben especificar y documentar todas las presunciones relacionadas
con la seguridad realizadas durante el desarrollo de la arquitectura del sistema.
Se deben especificar los subsistemas y/o componentes designados para cumplir los requisitos de
RAMS del sistema, incluido el impacto de fallos de causa común y de fallos múltiples.
Si se identifican nuevos peligros derivados de la arquitectura, los requisitos para controlarlos se deben
obtener de los nuevos peligros y se deben asignar a los subsistemas y/o componentes
correspondientes.
Si se utilizan subsistemas y/o componentes preexistentes para cumplir los requisitos del sistema, se
debe garantizar además que los requisitos para la integración de los subsistemas y/o componentes
preexistentes se cumplen y están claramente identificados.
Debería ser posible utilizar equipos comerciales (COTS), siempre que se demuestre la calidad de los
mismos. En el caso de las aplicaciones relacionadas con la seguridad, a nivel del sistema, se debe
demostrar que los posibles fallos de los productos comerciales (COTS) no pondrán en peligro los
requisitos de seguridad definidos, por ejemplo, los controlados por la arquitectura del sistema
(cuestión de integración).
En los casos en los que las funciones relacionadas con la seguridad se desarrollen con arreglo a un
código de buenas prácticas, la relación de estas funciones con el código de buenas prácticas utilizado
debe indicarse y justificarse en la arquitectura del sistema.
La realización de las funciones relacionadas con la seguridad se debe llevar a cabo de conformidad con
el código de buenas prácticas que corresponda.
Se deben especificar los criterios de aceptación, los procesos y procedimientos de aceptación, así como
la demostración de los subsistemas y/o componentes, incluidas sus interfaces, para garantizar el
cumplimiento de los requisitos del subsistema y/o de los componentes.
El plan de seguridad, el plan de RAM y el plan de validación de RAM y de seguridad se deben actualizar
(si procede) para garantizar que todas las tareas planificadas son coherentes con los requisitos de
RAMS emergentes del sistema tras la asignación.
NOTA Las áreas clave a las que prestar especial atención incluyen los requisitos para la independencia del personal y el
control de las interfaces del sistema para los casos en los que la funcionalidad de seguridad pueda verse
comprometida.
Las condiciones de aplicación relacionadas con la seguridad para las tareas futuras en las fases del
ciclo de vida de explotación, mantenimiento y retirada del servicio, se deben obtener del análisis de
RAMS del sistema en estudio realizado en esta fase 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-1:2018
7.6.3
- 84 -
Entregables
Se deben documentar los resultados de esta fase del ciclo de vida, incluyendo:
a)
la arquitectura del sistema (estructura de descomposición en subsistemas, etc.), incluida la
interfaz, análisis de especificaciones y de peligros del sistema (arquitectura y análisis de peligros
del subsistema y componentes);
b) la asignación de la especificación de requisitos de RAMS a subsistemas y/o componentes;
c)
los criterios de aceptación y los procedimientos de demostración y aceptación;
d) el plan de seguridad actualizado (si procede);
e)
el plan de RAM actualizado (si procede);
f)
el Plan de Validación de RAM actualizado (si procede);
g)
el Plan de Validación de la Seguridad actualizado (si procede);
h) las Condiciones de Aplicación Relacionadas con la Seguridad actualizadas (si procede);
i)
un registro de peligros actualizado (si procede).
Esta documentación debe incluir todas las hipótesis y justificaciones formuladas durante esta fase del
ciclo de vida.
7.7
Fase 6: Diseño e implementación
7.7.1
Objetivos
Los objetivos de esta fase del ciclo de vida son los siguientes:
a)
crear subsistemas y componentes que cumplan los requisitos de RAMS;
b) demostrar que los subsistemas y componentes cumplen los requisitos de RAMS;
c)
refinar los planes para futuras tareas del ciclo de vida que impliquen RAMS.
7.7.2
Actividades
Los subsistemas y componentes deben estar diseñados para cumplir los requisitos de RAMS.
El diseño de los subsistemas y componentes se debe llevar a cabo para cumplir los requisitos de RAMS.
Se deben perfeccionar las tareas de RAMS de las fases posteriores del ciclo de vida. Estas fases deben
incluir:
– la integración;
– la explotación y mantenimiento;
– la supervisión del comportamiento del sistema (si procede/también puede acordarse
contractualmente).
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-1:2018
Deben elaborarse procedimientos de explotación y mantenimiento. Dichos procedimientos deben
incluir toda la información pertinente para el suministro de repuestos, en particular la de elementos
con funciones relacionadas con la seguridad.
Se deben definir medidas de formación para el personal encargado de la explotación y el
mantenimiento, incluido el material de formación.
Se debe elaborar un proceso de fabricación capaz de producir subsistemas y componentes validados
en el ámbito RAMS con las actividades pertinentes definidas en el plan de seguridad para este proceso.
Los siguientes aspectos deberían tenerse en cuenta:
– protección frente al impacto ambiental;
– ensayos para la mejora de RAM;
– inspección y ensayo de los modos de fallo relacionados con RAMS.
Se debe definir un proceso de integración en el sistema que garantice la conformidad de los
subsistemas y componentes con RAMS. Las actividades relacionadas con la seguridad para este
propósito forman parte del Plan de Seguridad.
Los siguientes aspectos deberían tenerse en cuenta:
– las medidas para evitar errores de instalación;
– los ensayos de los subsistemas y componentes instalados;
– las actividades, definidas en el plan de seguridad, que sean relevantes para esta fase del ciclo de
vida.
Se debe realizar un análisis RAM.
Debe elaborarse un análisis de peligros con fines de seguridad.
Debe prepararse un caso de seguridad que justifique que el sistema en estudio, de acuerdo con su
diseño, cumple los requisitos de seguridad. El contenido y la estructura de la documentación del caso
de seguridad se deben ajustar a los requisitos establecidos en el apartado 8.2.
El plan de validación de RAMS se debe actualizar (si procede) para garantizar que todas las tareas
planificadas son coherentes con los requisitos de RAMS del sistema que van surgiendo tras su diseño.
Deben prepararse los procedimientos de instalación y puesta en servicio.
Las condiciones de aplicación relacionadas con la seguridad y las limitaciones para las tareas futuras a
realizar en las fases del ciclo de vida de explotación, mantenimiento y retirada del servicio, deben
obtenerse a partir de las desviaciones identificadas en esta fase del ciclo de vida.
7.7.3
Entregables
Se deben documentar los resultados de esta fase del ciclo de vida, incluyendo:
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-1:2018
a)
- 86 -
el análisis RAM;
b) el análisis de peligros;
c)
las Condiciones de Aplicación Relacionadas con la Seguridad actualizadas (si procede);
d) el registro de peligros actualizado (si procede);
e)
los procedimientos de instalación y puesta en servicio;
f)
los procedimientos de explotación y mantenimiento;
g)
las medidas de formación;
h) los planes para otras tareas del ciclo de vida;
i)
el plan RAM actualizado (si procede);
j)
el plan de seguridad actualizado (si procede);
k)
el Plan de Validación RAM actualizado (si procede);
l)
el Plan de Validación de la Seguridad actualizado (si procede);
m) el caso de seguridad (si procede).
NOTA La preparación del caso de seguridad es un entregable implícito del objetivo de la demostración de seguridad.
Esta documentación debe incluir todas las hipótesis y justificaciones formuladas durante esta fase del
ciclo de vida.
7.7.4
Tareas de verificación específicas
En esta fase del ciclo de vida se deben llevar a cabo, además de las tareas requeridas en el apartado
6.7.2, las siguientes tareas de verificación:
a)
verificación de que el diseño del subsistema y de los componentes cumple los requisitos de RAMS;
b) verificación de que la implementación de los subsistemas y componentes cumple con el diseño;
c)
verificación de que los planes de fabricación producen subsistemas y componentes validados en
cuanto a RAMS;
d) verificación de que todos los planes de actividades del ciclo de vida futuro son coherentes con los
requisitos de RAMS del sistema.
NOTA La verificación se basa en los resultados de análisis y ensayos.
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 -
7.8
Fase 7: Fabricación
7.8.1
Objetivos
UNE-EN 50126-1:2018
Los objetivos de esta fase del ciclo de vida son los siguientes:
a)
la fabricación de los subsistemas y componentes;
b) el establecimiento y aplicación de planes que garanticen el cumplimiento de RAMS.
7.8.2
Actividades
Se debe aplicar y poner en funcionamiento el proceso de fabricación preparado en la fase 6 del ciclo de
vida.
Se deben establecer planes que garanticen el cumplimiento de RAMS que incluyan:
a)
medidas que garanticen la calidad adecuadas para cumplir los requisitos de RAMS;
b) medidas de mejora y garantía de los procesos de fabricación, si procede;
c)
protección frente al impacto ambiental, si procede;
d) inspección y ensayo de los modos de fallo relacionados con RAMS.
Las condiciones de aplicación relacionadas con la seguridad para las tareas futuras de explotación,
mantenimiento y retirada del servicio deben obtenerse a partir de las desviaciones identificadas en
esta fase del ciclo de vida.
7.8.3
Entregables
Se deben documentar los resultados de esta fase del ciclo de vida, incluidos los aspectos relacionados
con RAMS de:
a)
los informes de garantía de la calidad (relativos al proceso de fabricación y a las medidas de
RAMS);
b) los informes de inspección y ensayos;
c)
la manipulación de materiales y organización logística;
d) el registro de peligros actualizado (si procede);
e)
las Condiciones de Aplicación Relacionadas con la Seguridad actualizadas (si procede);
f)
los casos de seguridad actualizados (si procede);
g)
el plan RAM actualizado (si procede);
h) el plan de seguridad actualizado (si procede);
i)
el Plan de Validación RAM actualizado (si procede);
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-1:2018
j)
- 88 -
el Plan de Validación de Seguridad actualizado (si procede).
Esta documentación debe incluir todas las hipótesis y justificaciones formuladas durante esta fase del
ciclo de vida.
7.9
Fase 8: Integración
7.9.1
Objetivos
Los objetivos de esta fase del ciclo de vida son los siguientes:
a)
montar e instalar el sistema integrado, la combinación total de subsistemas y los componentes
necesarios para formar el sistema completo;
b) demostrar que el sistema, los subsistemas y los componentes integrados funcionan
conjuntamente según lo definido por las interfaces;
c)
demostrar que los sistemas, subsistemas y componentes integrados cumplen sus requisitos de
RAMS;
d) iniciar los mecanismos de soporte del sistema.
7.9.2
Actividades
Los subsistemas y componentes se deben integrar de acuerdo con la planificación de la integración.
Debe demostrarse el cumplimiento de la funcionalidad de los sistemas y de los requisitos RAMS
especificados. El sistema integrado se debe instalar en un sistema de nivel superior. Por tanto, los
requisitos de esta fase del ciclo de vida se deben aplicar tanto a la integración de componentes y
subsistemas como a la incorporación de un sistema en el sistema superior. Esto podría considerarse
una integración en dos niveles para la que se aplican actividades similares.
En caso de introducir modificaciones o cambios en el sistema integrado, debe disponerse de un
procedimiento de reversión durante la integración (es decir, de la capacidad de volver a la versión
anterior).
En caso de introducir modificaciones o cambios, se debe realizar un análisis de impacto de la
arquitectura del sistema a partir de la fase 5 del ciclo de vida para garantizar que los subsistemas
interactúan con seguridad y realizan las funciones previstas después de dichas modificaciones o
cambios. El análisis de impacto debe evaluar en qué medida deben repetirse actividades del ciclo de
vida anteriores al cambio o modificación.
El sistema se debe someter a ensayo y a análisis de acuerdo con la planificación de integración del
sistema. Estos ensayos y análisis deben demostrar que todos los subsistemas y componentes del
sistema interactúan correctamente según las especificaciones de interfaz, de forma que realicen su
función prevista y no realicen funciones no previstas.
Durante la integración de los subsistemas y componentes del sistema, debe demostrarse el
cumplimiento de todas las condiciones de aplicación relacionadas con la seguridad definidas para
dichos subsistemas y componentes. Esto incluye, para los subsistemas desarrollados de acuerdo con
un código de buenas prácticas, las evidencias de la conformidad de la implementación con el Código de
Buenas Prácticas utilizado.
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-1:2018
Deben registrarse y documentarse las condiciones de aplicación relacionadas con la seguridad
heredadas de los subsistemas y componentes, que no puedan cumplirse a nivel del sistema técnico.
Se deben iniciar medidas adicionales de soporte al sistema relacionadas con los aspectos de RAMS que
incluyan:
a)
empezar con la formación del personal;
b) poner a disposición los procedimientos de soporte del sistema;
c)
establecer la provisión de repuestos;
d) establecer la provisión de herramientas.
Las condiciones de aplicación relacionadas con la seguridad para las fases futuras del ciclo de vida de
explotación, mantenimiento y retirada del servicio deben obtenerse a partir de las desviaciones
identificadas en esta fase del ciclo de vida.
7.9.3
Entregables
Se deben documentar los resultados de esta fase del ciclo de vida, incluyendo:
a)
la documentación de la instalación;
b) el informe de integración (si procede);
c)
las acciones adoptadas para resolver fallos e incompatibilidades;
d) los mecanismos de soporte del sistema;
e)
el registro de peligros actualizado (si procede);
f)
las Condiciones de Aplicación Relacionadas con la Seguridad actualizadas (si procede);
g)
los casos de seguridad actualizados (si procede);
h) el plan RAM actualizado (si procede);
i)
el plan de seguridad actualizado (si procede);
j)
el Plan de Validación RAM actualizado (si procede);
k)
el Plan de Validación de Seguridad actualizado (si procede).
Esta documentación debe incluir todas las hipótesis y justificaciones formuladas durante esta fase del
ciclo de vida.
7.9.4
Tareas de verificación específicas
En esta fase del ciclo de vida se deben llevar a cabo, además de las tareas requeridas en el apartado
6.7.2, las siguientes tareas de verificació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-1:2018
- 90 -
– evaluar que todas los condiciones de aplicación relacionadas con la seguridad (SRAC) de los
subsistemas/componentes integrados se cumplen durante la integración.
7.10 Fase 9: Validación del sistema
7.10.1
Objetivos
Los objetivos de esta fase del ciclo de vida son los siguientes:
a)
confirmar mediante exámenes y la aportación de evidencias objetivas que el sistema en estudio,
en combinación con sus condiciones de aplicación relacionadas con la seguridad, cumple los
requisitos de RAMS;
b) confirmar o actualizar el caso de seguridad del sistema en estudio, según los resultados de la
validación.
7.10.2
Actividades
Los requisitos generales sobre las actividades que han de llevarse a cabo se describen en el apartado
6.7.3.
Dependiendo del nivel de integridad de la seguridad del sistema en estudio, las actividades de
validación deben incluir también:
– El registro de peligros debe revisarse y actualizarse para registrar cualquier peligro residual
identificado durante la validación del sistema y para garantizar que los riesgos derivados de tales
peligros se gestionan eficazmente.
– El plan de seguridad debe revisarse debido a que es de permanente aplicación.
– Se debe actualizar el caso de seguridad del sistema en estudio. El caso de seguridad debe justificar
que el sistema en estudio cumple con los requisitos de seguridad del sistema.
Se puede iniciar un período de prueba para resolver los problemas del sistema que puedan aparecer
en servicio. En este caso, se debe considerar la necesidad de demostrar la seguridad del sistema antes
de la explotación en periodo de pruebas y la explotación comercial.
Se debe establecer y aplicar un proceso para la adquisición y evaluación de los datos de explotación y
mantenimiento como entradas de información para un proceso de mejora del sistema.
Si el sistema ha sido sometido a un análisis de impacto según lo establecido en el apartado 7.9.2, se
debe evaluar la idoneidad de dicho análisis.
Las condiciones de aplicación relacionadas con la seguridad para las tareas futuras del ciclo de vida de
explotación, mantenimiento y retirada del servicio deben obtenerse a partir de las desviaciones
identificadas en esta fase del ciclo de vida.
Debe documentarse la recopilación de todas las condiciones de aplicación relacionadas con la
seguridad (por ejemplo, en un registro) para las fases futuras del ciclo de vida de explotación,
mantenimiento y retirada del servicio.
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 -
7.10.3
UNE-EN 50126-1:2018
Entregables
Se deben documentar los resultados de esta fase del ciclo de vida, incluyendo:
– el informe de validación RAM;
– el informe de validación de la seguridad;
– el registro de peligros actualizado (si procede);
– el plan de seguridad actualizado (si procede);
– el caso de seguridad actualizado (si procede);
– las Condiciones de Aplicación Relacionadas con la Seguridad actualizadas (si procede);
– el proceso para la adquisición y evaluación de los datos de explotación.
En esta fase del ciclo de vida se debe elaborar un Informe de Validación que incluya:
a)
la identificación y nombre de:
–
el sistema en estudio,
–
los documentos y otros elementos utilizados para la validación,
–
los procesos, herramientas de soporte técnico y equipos utilizados, junto con los datos de
calibración,
–
los modelos de simulación utilizados, si procede;
b) la confirmación de que se han cumplido el proceso y las actividades definidas en el plan de
validación. Las desviaciones con respecto al plan de validación deben registrarse y justificarse;
c)
la evaluación del resultado y la cobertura de los requisitos trazados en el desarrollo y verificación;
d) la confirmación de que el desarrollo y la verificación han realizado acciones correctivas de
acuerdo con los procesos y los procedimientos de gestión de cambios y donde las desviaciones
hayan sido claramente identificadas;
e)
evaluar la cobertura de los requisitos para el sistema en estudio mediante ensayos y/o análisis;
f)
la identificación de los ensayos definidos y realizados por el validador, si hubiera;
g)
evaluar la exactitud, coherencia y adecuación de la certificación conforme a las normas
relacionadas correspondientes a las tecnologías requeridas;
NOTA Las normas correspondientes a la tecnología se definen en la especificación de requisitos del sistema.
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-1:2018
- 92 -
h) la conclusión de los resultados de la validación y si el sistema en estudio cumple los requisitos de
seguridad para su uso previsto en el entorno definido.
El caso de seguridad puede cubrir los siguientes puntos y el informe de validación puede referirse a
este documento en cuanto a:
– evaluación de la conformidad del proceso de desarrollo y del sistema en consideración validado con
respecto a los requisitos/actividades definidos en esta norma europea;
– evaluación de la conformidad del proceso de desarrollo con respecto a los planes (por ejemplo, con
el plan de seguridad, el plan de gestión de la calidad);
– confirmación de la exactitud, coherencia y adecuación del proceso de verificación (ensayos, análisis
y revisión) con respecto a la planificación de la verificación y a los informes de verificación;
– identificación y clasificación de todas las desviaciones y su relación con las condiciones de
aplicación relacionadas con la seguridad derivadas de dichas desviaciones en términos de riesgo.
Tomar en consideración las medidas externas de reducción de riesgos;
– comprobación de la exactitud, coherencia y adecuación de los manuales de instalación, puesta en
servicio, mantenimiento y explotación del sistema en estudio.
7.11 Fase 10: Aceptación del sistema
7.11.1
Objetivos
Los objetivos de esta fase del ciclo de vida son los siguientes:
a)
evaluar la conformidad de la combinación total de subsistemas, componentes, interfaces y
condiciones de aplicación relacionadas con la seguridad respecto al conjunto de requisitos RAMS;
b) aceptar el sistema para su puesta en servicio.
NOTA En esta norma europea, el término "aceptación del sistema" se utiliza únicamente para los aspectos técnicos del
procedimiento de aceptación. En esta norma no se consideran los aspectos legales de la aceptación del sistema. Se
aconseja aclarar previamente los aspectos legales de la aceptación del sistema entre el cliente y el proveedor.
7.11.2
Actividades
Todas las tareas de verificación y validación del sistema, en particular la verificación y validación de
RAMS y el caso de seguridad, deben evaluarse con arreglo a los criterios de aceptación de riesgos
definidos.
NOTA Los criterios de aceptación de riesgos vienen determinados por acuerdos contractuales o por el marco legal y se
especifican en la fase 4 del ciclo de vida.
Los resultados de esta evaluación deben registrarse en un informe de aceptación. El informe de
aceptación debería incluir la confirmación de que el producto, sistema o proceso suministrado es apto
para su puesta en servicio.
La entidad que acepte el sistema (responsable del servicio ferroviario u otro) debe realizar las
siguientes tareas:
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 -
a)
UNE-EN 50126-1:2018
evaluación del informe de aceptación respecto a los criterios de aceptación definidos;
b) evaluación del plan de seguridad con respecto a su aplicabilidad continua, incluida la posible
necesidad de una evaluación independiente de la seguridad (si procede);
c)
evaluación del registro de peligros actualizado.
7.11.3
Entregables
Se deben documentar los resultados de esta fase del ciclo de vida, incluyendo:
– un informe de la Evaluación Independiente de la Seguridad (si procede);
– la aprobación de las Condiciones de Aplicación Relacionadas con la Seguridad (si procede);
– un informe de aceptación.
Esta documentación debe incluir todas las hipótesis y justificaciones formuladas durante esta fase del
ciclo de vida.
7.12 Fase 11: Explotación, mantenimiento y control del rendimiento del sistema
7.12.1
Objetivos
El objetivo de esta fase es explotar, mantener y dar soporte al sistema en estudio de forma que se
mantenga el cumplimiento de los requisitos de RAMS. Esto incluye el control y la evaluación continuos
de los resultados de RAMS del sistema y la creación de medidas para abordar las deficiencias y lograr
mejoras.
7.12.2
Actividades
Antes del inicio de esta fase del ciclo de vida, el fabricante debería proporcionar al cliente toda la
información necesaria para formular planes y procedimientos de explotación, mantenimiento y
supervisión del comportamiento del sistema, y permitir que se pueda mantener el cumplimiento de los
requisitos de RAMS. Esta información debe incluir todas las Condiciones de Aplicación Relacionadas
con la Seguridad (SRAC) identificadas en el curso de la verificación y validación.
Los Planes de Explotación y Mantenimiento deben incluir lo siguiente:
1) Una explicación del estado de explotación: Las condiciones que se dan en cada
sistema/subsistema/hardware deberían definirse para proporcionar al personal encargado de la
explotación y mantenimiento una comprensión suficiente de las siguientes situaciones:
a)
puesta en marcha: se deberían describir las condiciones de puesta en marcha del sistema,
subsistema o hardware en el momento en el que se le suministra energía por primera vez, o
tras una parada por una interrupción de la alimentación eléctrica u otra causa;
b) explotación normal: una vez que el sistema/subsistema/hardware haya finalizado con éxito
su inicialización, se deben definir las condiciones durante su explotación normal;
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-1:2018
c)
- 94 -
cambio de estado: si el sistema/subsistema o el hardware en el que está configurado tiene la
posibilidad de cambiar a un sistema/subsistema de reserva en frío o en caliente, las
condiciones definidas en los puntos a) y b) deberían redefinirse para esta rutina de cambio de
estado. También se debe definir claramente la reacción del sistema/subsistema o hardware al
cambio de módulos defectuosos;
d) apagado: cuando un sistema/subsistema o hardware se apague intencionadamente por un
cambio de configuración o una puesta fuera de servicio, o involuntariamente por un fallo en la
alimentación eléctrica, se deben definir todas las condiciones pertinentes.
2) El mantenimiento debería definirse con respecto a:
a)
las tareas de mantenimiento a las que se somete al sistema in situ o en las instalaciones
designadas para el mantenimiento ordinario;
b) la reparación o renovación de sistemas, subsistemas o hardware que no se realicen in situ o
que se realicen en instalaciones no clasificadas como de mantenimiento ordinario, por
ejemplo, las revisiones a mitad de la vida útil realizadas por el cliente y el fabricante;
c)
mantenimiento preventivo;
d) mantenimiento correctivo;
e)
herramientas de mantenimiento: para cada nivel de mantenimiento, deberían definirse las
herramientas de mantenimiento disponibles para el personal.
3) Un análisis de los factores humanos y de los requisitos de competencia del personal encargado del
mantenimiento que puedan tener impacto en alcanzar el objetivo de RAMS requerido.
4) Un análisis de los factores humanos y de los requisitos de competencia del personal encargado de
la explotación que puedan tener impacto en alcanzar el objetivo de RAMS requerido.
Se deben implementar procedimientos de explotación y mantenimiento, especialmente en lo que se
refiere al rendimiento del sistema y a los costes del ciclo de vida. Esto requiere considerar el producto,
sistema o proceso en su entorno de explotación, por ejemplo, incluyendo la aplicación de medidas
externas de reducción de riesgos.
El cumplimiento de los requisitos de RAMS se debe garantizar a lo largo de esta fase del ciclo de vida
mediante:
a)
la revisión y actualización periódica de los planes y procedimientos de explotación y
mantenimiento;
b) la conformidad con los planes y procedimientos de explotación;
c)
la conformidad con los planes y procedimientos de mantenimiento;
d) la revisión periódica de la documentación de formación del sistema;
e)
revisión y actualización periódicas (si procede) de un registro de riesgos de explotació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
- 95 -
UNE-EN 50126-1:2018
f)
la garantía del cumplimiento de las Condiciones de Aplicación Relacionadas con la Seguridad
(SRAC);
g)
la investigación y tratamiento de incidentes y accidentes peligrosos y la garantía de una respuesta
rápida en caso de avería;
h) la definición e implementación de medidas de mitigación, si procede, para los sistemas sometidos
a modificación, para asegurar la integridad general del sistema hasta que se haya completado la
modificación o se hayan investigado y corregido los problemas notificados;
i)
la conformidad con los acuerdos de soporte, incluidos los acuerdos logísticos, los repuestos, las
reparaciones, las herramientas, la calibración y las medidas de calidad para prevenir o detectar
los errores que se produzcan durante el almacenamiento y el transporte;
j)
el mantenimiento del Sistema de Comunicación de Fallos y Medidas Correctivas (FRACAS).
NOTA 1 El registro de peligros de explotación se basa en el archivo de peligros extraído del registro de peligros resultante de
la fase 10 del ciclo de vida.
La revisión y actualización del Plan de Explotación y Mantenimiento debe incluir las cuestiones
planteadas y tratadas durante la fase inicial de explotación y mantenimiento y en las etapas
posteriores aplicables.
Se debe implementar un proceso para:
a) la adquisición de datos de indicadores RAMS de rendimiento;
b) el registro de datos de indicadores RAMS de rendimiento, y los datos de análisis y evaluación
correspondientes, por ejemplo, mediante un Sistema de Comunicación de Fallos y Medidas
Correctivas (FRACAS).
Se debe registrar la línea de base del sistema a lo largo de toda su vida operativa y se debe mantener
su trazabilidad bajo el control de la gestión de la configuración.
NOTA 2 Esto es de especial importancia cuando se descubren averías críticas que es necesario corregir en más de una
instalación. Es posible que los fabricantes y encargados de mantenimiento tengan que realizar gestiones
complementarias para la gestión de la configuración, de modo que el fabricante pueda realizar la trazabilidad de la
línea de base de los sistemas suministrados a clientes concretos y que los encargados de mantenimiento
individuales puedan realizar la trazabilidad de la ubicación de elementos individuales.
El proceso del Sistema de Comunicación de Fallos y Medidas Correctivas (FRACAS) ha de proporcionar
continuamente información al responsable de la seguridad de la explotación, al diseñador, al
fabricante, al director de operaciones y al responsable de mantenimiento sobre cualquier fallo o
defecto (y las posibles causas) detectados durante el servicio. Los fallos pueden tener diversas causas,
entre las que se incluyen fallos de componentes, errores de explotación, de mantenimiento y otros
errores. Por tanto, es imperativo que el proceso de presentación de informes sea claro y lógico y que
exista un foro en el que todas las partes interesadas puedan ponerse de acuerdo sobre la fuente más
probable de un fallo y, por tanto, sobre las medidas de investigación y correcció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-1:2018
- 96 -
NOTA 3 1) Puede ser necesario que diferentes entidades conserven los registros del Sistema de Comunicación de Fallos y
Medidas Correctivas (FRACAS) complementarios. Las organizaciones encargadas de las tareas de
mantenimiento pueden tener un Sistema de Comunicación de Fallos y Medidas Correctivas (FRACAS) genérico
que cubra muchos tipos diferentes de sistemas, de los que son responsables, mientras que los fabricantes
pueden tener un FRACAS que abarque sistemas suministrados a una variedad de clientes diferentes. El
fabricante ha de poder diagnosticar fallos de componentes que no son accesibles para los encargados de
mantenimiento.
2) La referencia a accidentes, peligros y causas ha de hacerse preferiblemente de manera coherente dentro del caso
de seguridad y otras herramientas y procesos de supervisión del comportamiento del sistema. Esto ayudará a las
respectivas organizaciones a identificar cuestiones y tendencias.
El Sistema de Comunicación de Fallos y Medidas Correctivas (FRACAS) se debe mantener durante todo
el ciclo de vida de explotación y mantenimiento. A fin de garantizar que se aborden las cuestiones
prioritarias, los fallos y defectos deberían clasificarse en categorías, por cuestiones de seguridad y de
fiabilidad, en función de los distintos niveles de gravedad/criticidad. Como mínimo, el Sistema de
Comunicación de Fallos y Medidas Correctivas (FRACAS) debe contar con información sobre fallos y
defectos identificados durante la explotación y el mantenimiento. Esta información debe incluir:
a)
fecha y hora a la que se produjo el fallo;
b) causa del fallo;
c)
descripción detallada del fallo;
d) medidas correctivas adoptadas;
e)
clasificación de seguridad del fallo.
f)
cuándo y cómo se han detectado los fallos y defectos (por ejemplo, durante la explotación o
durante un mantenimiento programado);
g)
los efectos de los fallos y defectos hasta el nivel del sistema ferroviario.
Los registros del Sistema de Comunicación de Fallos y Medidas Correctivas (FRACAS) se deben revisar
periódicamente para determinar si es necesario introducir mejoras en los siguientes aspectos:
h) procedimientos y manuales de explotación y mantenimiento;
i)
documentación de formación del sistema;
j)
registro de riesgos de explotación;
k)
diseño del sistema;
l)
aspectos humanos de la explotación y mantenimiento.
Cuando se propongan cambios, se debe realizar un análisis de impacto para cada solicitud de cambio.
El análisis debe incluir una revisión del impacto en:
m) el desempeño de la seguridad operacional/funcional del sistema/subsistema o del hardware;
n) las interfaces del sistema/subsistema/hardware;
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
- 97 -
o)
UNE-EN 50126-1:2018
el desempeño de la seguridad operacional/funcional del sistema/subsistema o hardware
adyacente;
p) los trabajos de instalación de una modificación, teniendo en cuenta el sistema/subsistema y
hardware adyacentes que puedan verse afectados por fallos sistemáticos.
El análisis de impacto debe dar lugar a una decisión sobre las partes del ciclo de vida de la seguridad
que se repetirán para la modificación; se debe actualizar toda la documentación pertinente para las
etapas del ciclo de vida efectuadas, con la misma profundidad y calidad que la documentación original
que se produjo durante el desarrollo del sistema. Los detalles y resultados de la modificación, el
análisis de riesgos y los ensayos se deben incluir en el caso de seguridad.
Todos los cambios y el sistema/subsistema o hardware identificados como en situación de riesgo se
deben someter a ensayos para comprobar su correcto funcionamiento una vez finalizado el cambio.
Para cada recomendación identificada se debe decidir si la recomendación debe implementarse o no.
Estas decisiones deben estar justificadas y registradas.
7.12.3
Entregables
Se deben documentar los resultados de esta fase del ciclo de vida, incluyendo:
a)
el sistema y la documentación de soporte actualizados, según proceda, dentro de esta fase del
ciclo de vida;
b) los planes y registros adecuados para llevar a cabo la trazabilidad de las tareas de RAMS
realizadas en esta fase del ciclo de vida (por ejemplo, pruebas de la correcta ejecución del Plan de
Explotación y Mantenimiento);
c)
los informes de los análisis y valoraciones de los indicadores de RAMS;
d) las recomendaciones identificadas y el registro de las decisiones asociadas;
e)
un registro de peligros de explotación actualizado (si procede);
f)
la solicitud de cambio con análisis de impacto sobre la reaplicación del ciclo de vida del sistema;
g)
las especificaciones de diseño y los requisitos actualizados, en caso de impacto;
h) el caso de seguridad del sistema actualizado según sea necesario, para incluir la modificación del
diseño y/o el análisis de riesgos (según proceda);
i)
los planes y procesos de Explotación y Mantenimiento actualizados.
Esta documentación debe incluir todas las hipótesis y justificaciones formuladas durante esta fase del
ciclo de vida.
7.12.4
Tareas de verificación específicas
No existen requisitos de verificación específicos para esta fase del ciclo de vida además de las tareas
requeridas en el apartado 6.7.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-1:2018
- 98 -
7.13 Fase 12: Retirada del servicio
7.13.1
Objetivos
El objetivo de esta fase del ciclo de vida es controlar los efectos de RAMS en las tareas de retirada del
servicio y eliminación del sistema.
7.13.2
Actividades
Debe determinarse el impacto de RAMS en la retirada del servicio y eliminación de cualquier sistema o
instalación externa pertinente.
Se debe planificar la retirada del servicio, incluido el establecimiento de procedimientos para:
a)
el cese del servicio del sistema de forma segura;
b) el desmontaje seguro del sistema.
Dado que los sistemas o instalaciones externas pueden verse afectados, estos sistemas o instalaciones
también han de tenerse en cuenta. Se ha de considerar que la eliminación puede representar una
modificación del sistema o instalación externos.
7.13.3
Entregables
Se deben documentar los resultados de esta fase del ciclo de vida, incluyendo:
– el impacto en RAMS asociadas al cese del servicio/desmontaje del sistema;
– un informe de retirada del servicio.
Esta documentación debería incluir todas las hipótesis y justificaciones formuladas durante esta fase
del ciclo de vida.
8 Caso de seguridad
8.1
Objeto de un caso de seguridad
El caso de seguridad consiste en la justificación estructurada y documentada de la seguridad que
aporta las evidencias de cómo el sistema en cuestión cumple los requisitos de seguridad especificados,
dentro del alcance definido de su uso propuesto. Esto:
• permite a los usuarios del sistema confiar en que el sistema cumple con los requisitos de seguridad
especificados;
• demuestra que el sistema cumple los requisitos de seguridad especificados, determinados de
acuerdo con los requisitos especificados en la serie de Normas EN 50126;
• proporciona una base para una evaluación independiente de la seguridad;
• proporciona las Condiciones de Aplicación Relacionadas con la Seguridad (SRAC).
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
- 99 -
UNE-EN 50126-1:2018
NOTA Un caso de seguridad se utiliza para proporcionar a una parte la garantía de otra. En esta norma, la parte que
desarrolla el sistema en estudio (por ejemplo, el proveedor o la entidad contratante) proporciona en última instancia
la garantía a la parte responsable de la explotación y el mantenimiento del ferrocarril (por ejemplo, el operador de
material rodante o el administrador de infraestructuras).
Existen dos limitaciones habituales en el alcance de un caso de seguridad:
• la demostración de que los requisitos de seguridad son correctos y el hecho de que la evaluación de
riesgos correspondiente suele ser externa al caso de seguridad;
• las pruebas del cumplimiento de las Condiciones de Aplicación Relacionadas con la Seguridad
(SRAC) identificadas en el caso de seguridad no suelen figurar en el propio caso de seguridad.
Los tipos de casos de seguridad, las dependencias y las relaciones se definen en el capítulo 6 de la
Norma EN 50126-2:2017.
8.2
Contenido de un caso de seguridad
El caso de seguridad debe contener, como mínimo, lo siguiente:
1.
Definición del sistema en estudio. Incluye:
–
subsistemas/equipos clave;
–
arquitectura y comportamiento esperado;
–
interfaces y entorno de explotación;
–
requisitos de seguridad;
–
definición de la configuración/versión del sistema en estudio a la que se aplica el caso de
seguridad;
–
referencia a los requisitos de seguridad de entrada, así como a los análisis de evaluación de
riesgos correspondientes.
2.
Informe de Gestión de la Calidad. Incluye:
–
actividades y evidencias de gestión de la calidad.
3.
Informe de Gestión de la Seguridad. Incluye:
–
actividades y evidencias de gestión de la seguridad.
4.
Informe Técnico de Seguridad. Incluye actividades de garantía de la seguridad y pruebas, que
incluyen:
–
garantía de seguridad en condiciones libres de averías;
–
garantía de seguridad en caso de fallos y errores;
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-1:2018
- 100 -
–
garantía de seguridad con influencias externas adversas;
–
Condiciones de Aplicación Relacionadas con la Seguridad (SRAC).
5.
Casos de seguridad relacionados. Incluye:
–
referencias a los casos de seguridad de todos los subsistemas/equipos de los que depende el caso
de seguridad principal.
–
la demostración de que todas las condiciones de aplicación relacionadas con la seguridad
especificadas en cada uno de los casos de seguridad de los subsistemas/equipos correspondientes
se cumplen en el caso de seguridad principal o se trasladan a las condiciones de aplicación
relacionadas con la seguridad del caso de seguridad principal.
6.
Conclusión. Incluye:
–
un resumen de las pruebas presentadas en las partes anteriores del caso de seguridad;
–
una lista de todas las observaciones de seguridad específicas, y
–
declaración de que el sistema en estudio es lo suficientemente seguro, a condición de que se
cumplan las condiciones de aplicación especificadas.
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
- 101 -
UNE-EN 50126-1:2018
Anexo A (Informativo)
Plan de RAMS
A.1 Generalidades
En el anexo A se presenta un ejemplo de procedimiento a modo de esquema para elaborar un plan
básico de RAM/plan de seguridad y un ejemplo de plan básico de RAMS (plan de RAM/plan de
seguridad). También enumera algunos métodos y herramientas para la gestión y el análisis de RAMS.
El proveedor debería establecer un plan de RAMS para facilitar el cumplimiento de los requisitos de
RAMS para la aplicación en consideración.
A.2 Procedimiento
A continuación se ofrece un ejemplo de procedimiento para un plan de RAMS básico.
1.
Definir las fases de ciclo de vida apropiadas, respectivamente, fases del proyecto que estén en
línea con el proceso empresarial de la empresa;
Resultado: Se establecen las fases del ciclo de vida o proyecto de la empresa.
2.
Asignar a cada fase del ciclo de vida o del proyecto la RAM relacionada con la fase y las tareas de
seguridad necesarias para cumplir los requisitos específicos del proyecto y del sistema;
Resultado: Se identifican todas las tareas de RAMS necesarias en el ciclo de vida o proyecto.
3.
Definir las responsabilidades en la empresa para llevar a cabo cada tarea de RAMS;
Resultado: Se identifican el personal responsable y los recursos de RAMS necesarios.
4.
Se definen las instrucciones, herramientas y documentos de referencia necesarios para cada tarea
de RAMS;
Resultado: Gestión de RAMS documentada
5.
Las actividades de RAMS se implementan en los procesos de la empresa.
Resultado: Proceso integrado de gestión de RAMS
A.3 Ejemplo de plan de RAMS básico
En la tabla A.1 se presenta un esquema para un plan básico de RAMS. El esquema consiste en un
ejemplo de un conjunto de tareas que podrían aplicarse a un proyecto concreto.
NOTA Las fases de proyecto propuestas se complementan con las fases del ciclo de vida definidas en el capítulo 7 y
resumidas en la tabla 1.
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-1:2018
- 102 -
Tabla A.1 – Ejemplo de un esquema de plan básico de RAMS
Proyecto-Fase
Tareas de RAMS
Pre-Adquisición
Evaluar los objetivos de RAMS de la aplicación
específica
Estudio de viabilidad
Evaluar los requisitos de RAMS
Responsabilidad
Evaluar datos y experiencia pasados de RAMS
Identificar la influencia en la seguridad impuesta
por la aplicación específica
Consultar al cliente sobre RAMS (si es necesario)
Invitación a la fase de
licitación
Realizar un análisis preliminar de RAMS
(condiciones más desfavorables)
Sistema de asignación de los requisitos de RAMS
(Subsistemas/equipos, otros sistemas relevantes,
etc.)
Realizar análisis de peligros del sistema y de
riesgos de seguridad
Realizar análisis de riesgos relacionados con RAM
Preparar una futura evaluación de datos de RAMS
Comentarios sobre RAMS en cada apartado
Contrato
Negociaciones
Revisión/actualización del análisis preliminar de
RAMS y asignación de RAMS
Procesamiento del
pedido: Definición de
los requisitos del
sistema
Establecimiento de la gestión de RAMS específica
del proyecto
Especificar los requisitos de RAMS del sistema
(generales)
Establecer un plan de RAMS (¿Es suficiente un
plan estándar de RAMS?)
Asignar requisitos de RAMS a subcontratistas,
proveedores
Definir criterios de aceptación de RAMS
(generales)
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
Documento
de referencia
- 103 -
Proyecto-Fase
Procesamiento del
pedido: Diseño e
Implementación
Tareas de RAMS
UNE-EN 50126-1:2018
Responsabilidad
Documento
de referencia
Análisis de fiabilidad (por ejemplo, AMFE)
Análisis de seguridad (por ejemplo, FMECA), si
procede
Análisis de mantenimiento/reparación; definir la
política de mantenimiento/reparación
Análisis de disponibilidad basado en la política de
mantenimiento/reparación
Revisión de RAMS
Estimación del coste del Ciclo de vida
Demostración de RAMS, recopilación de pruebas
AMFE del diseño/fabricación
Ensayos de fiabilidad y mantenibilidad, si procede
Adquisición
Proporcionar especificaciones de RAMS para
subcontratistas/proveedores
Fabricación/Ensayos
Garantía de calidad/de proceso relacionada con
RAMS
Puesta en servicio/
Aceptación
Realizar demostración de RAM
Preparar un caso de seguridad para la aplicación
específica
Iniciar la evaluación de datos de RAMS
Ensayos de RAM durante la explotación inicial,
análisis y cribado de datos
Explotación/
Mantenimiento
Explotación y mantenimiento provisionales
(Política de mantenimiento/reparación)
Formación del personal de explotación y
mantenimiento
Evaluación de datos de RAMS
Evaluación del coste del Ciclo de vida
Revisión del rendimiento
A.4 Lista de técnicas
A continuación se enumeran algunos métodos e instrumentos apropiados para llevar a cabo y
gestionar las actividades de RAMS. La elección del instrumento pertinente dependerá del sistema en
estudio y de la criticidad, complejidad, novedad, etc. del sistema.
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-1:2018
1.
Procedimientos para la revisión formal del diseño con énfasis en RAMS, utilizando algunas listas
de comprobación generales y específicas de la aplicación, como por ejemplo:
EN 61160:2005
2.
- 104 -
Revisión de diseño.
Procedimientos para realizar análisis de RAM "descendentes" (métodos deductivos) y
"ascendentes" (métodos inductivos) preliminares, en el peor de los casos y en profundidad para
estructuras simples y complejas de un sistema funcional.
En la siguiente norma se ofrece una visión general de los procedimientos, métodos, ventajas y
desventajas, entrada de información y otros requisitos utilizados en las distintas técnicas:
IEC 60300-3-1
Gestión de la confiabilidad. Parte 3-1: Guía de aplicación. Técnicas de
análisis de la confiabilidad. Guía metodológica.
Las diversas técnicas de análisis de RAM se describen en distintas normas, algunas de ellas son las
siguientes:
IEC 60706
Guía para la mantenibilidad de equipos.
IEC 60706-1
Parte 1: Secciones 1, 2 y 3: Introducción, requisitos y programa de
mantenibilidad.
EN 60706-2
Parte 2: Estudios y requisitos de mantenibilidad durante la fase de
diseño y de desarrollo.
EN 60706-3
Parte 3: Verificación y recogida, análisis y presentación de datos.
EN 60706-5
Parte 5: Facilidad de ensayo y ensayos de diagnóstico.
IEC 60706-6
Parte 6: Sección 9: Métodos estadísticos en la evaluación de la
mantenibilidad.
EN 60812
Técnicas de análisis de la fiabilidad de sistemas. Procedimiento de
análisis de los modos de fallo y de sus efectos (AMFE).
EN 61025
Análisis por árbol de fallos (AAF).
EN 61078
Técnicas de análisis de la confiabilidad. Método del diagrama de bloques
de la fiabilidad y métodos booleanos.
EN 61165
Aplicación de las técnicas de Markov.
La disponibilidad de datos estadísticos de "RAM" para los componentes utilizados en un diseño
(normalmente: tasas de fallo, tasas de reparación, datos de mantenimiento, modos de fallo, tasas
de incidencias, distribución de datos e incidencias aleatorias, etc.) es fundamental para el análisis
de RAM, por ejemplo:
EN 61709
Componentes electrónicos. Fiabilidad. Condiciones de referencia para
tasas de fallo y modelos de conversión en función de los esfuerzos.
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
- 105 -
MIL-HDBK-217F
UNE-EN 50126-1:2018
Notice 2 Reliability Prediction for Electronic Systems (Predicción de
Fiabilidad para Sistemas Electrónicos).
También existen programas informáticos para el análisis de RAM de un sistema y para el análisis
de datos estadísticos.
3.
Procedimientos para realizar análisis de peligros y análisis de seguridad/riesgos
Algunos de ellos se describen en:
MIL-STD-882D
Standard Practise for System Safety (Práctica Habitual para la Seguridad
del Sistema).
MIL-HDBK-764 (MI)
System Safety Engineering Design Guide For Army Materiel (Guía de
diseño de ingeniería de seguridad de sistemas para material militar).
Las mismas técnicas básicas y métodos de análisis enumerados para RAM (punto 3) son aplicables
para el análisis de la seguridad/riesgos.
Véanse también las Partes 1-7 de la Norma IEC 61508 con el título "Seguridad funcional de los
sistemas eléctricos/electrónicos/electrónicos programables relacionados con la seguridad", y en
concreto las siguientes partes:
4.
EN 61508-5:2010
Parte 5: Ejemplos de métodos de determinación de los niveles de
integridad de seguridad.
EN 61508-7:2010
Parte 7: Presentación de técnicas y medidas.
Planes y procedimientos de ensayos de RAMS
Este paso tiene por objeto someter a ensayo el comportamiento operativo a largo plazo de los
componentes, equipos o sistemas y demostrar el cumplimiento de los requisitos. Además, los
resultados de análisis y ensayos de RAMS se utilizan para diseñar programas de mejora de RAMS,
por ejemplo:
IEC 60605
Ensayo de fiabilidad de equipos.
IEC 60605-2
Parte 2: Diseño de los ciclos de ensayo.
IEC 60605-3-1
Parte 3: Condiciones de ensayo preferentes. Equipos portátiles de
interior. Bajo grado de simulación.
IEC 60605-4
Parte 4: Procedimientos estadísticos para la distribución exponencial.
Estimaciones por puntos, intervalos de confianza, intervalos de
predicción e intervalos de tolerancia.
IEC 60605-6
Parte 6: Ensayos para la validez de la tasa de fallo constante o de los
supuestos de intensidad de fallo constante.
EN 61014
Programas de crecimiento de fiabilidad.
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-1:2018
- 106 -
IEC 61070
Procedimientos de ensayo de conformidad con la disponibilidad en
régimen permanente.
IEC 61123
Ensayos de fiabilidad. Planes de ensayo de conformidad con una
proporción de éxitos.
De mayor importancia es la evaluación de los datos de RAMS en campo (ensayos de RAMS durante
la explotación), por ejemplo:
5
EN 60300-3-2
Gestión de la confiabilidad. Parte 3: Guía de aplicación. Sección 2:
Recogida de datos de confiabilidad en la explotación.
IEC 60319
Presentación y especificación de datos de fiabilidad de componentes
electrónicos.
Procedimientos/herramientas para realizar análisis LCC (coste del ciclo de vida)
Existen programas informáticos para el análisis LCC.
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
- 107 -
UNE-EN 50126-1:2018
Anexo B (Informativo)
Ejemplos de parámetros para ferrocarriles
B.1 Generalidades
A continuación se muestran ejemplos de parámetros y símbolos típicos, adecuados para su uso en
aplicaciones ferroviarias.
NOTA Algunos parámetros de los ejemplos se utilizan sólo en sectores específicos, por ejemplo, material rodante.
En general, cualquier parámetro basado en el tiempo como MTBF (tiempo medio de funcionamiento
entre fallos) puede convertirse/obtenerse a partir de la distancia recorrida o ciclos de trabajo
realizados respectivamente.
La definición y directrices generales detalladas sobre el tratamiento matemático de los términos de
RAM se proporcionan en la Norma EN 61703.
B.2 Parámetros de fiabilidad
Tabla B.1 – Ejemplos parámetros de fiabilidad
Parámetro
Símbolo
Unidades
Tasa de fallo
λ(t)
1/tiempo, 1/distancia, 1/ciclo
Tiempo medio operativo
MUT
tiempo (distancia, ciclo)
Tiempo medio hasta el fallo a (para elementos no
reparables)
MTTF
tiempo (distancia, ciclo)
Tiempo medio de funcionamiento entre fallos a (para
elementos reparables)
MTBF
tiempo (distancia, ciclo)
Probabilidad de fallo
F(t)
sin unidades
Fiabilidad (Probabilidad de éxito)
R(t)
sin unidades
a
De acuerdo con la Norma EN 61703 y la Norma IEC 60050-191-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-1:2018
- 108 -
B.3 Parámetros de mantenibilidad
Tabla B.2 – Ejemplos de parámetros de mantenibilidad
Parámetro
Símbolo
Unidades
Tiempo de caída medio
MDT
tiempo (distancia, ciclo)
Tiempo medio entre mantenimientos a
MTBM
tiempo (distancia, ciclos)
MTBM (correctivo o preventivo)
MTBM(c), MTBM(p) tiempo (distancia, ciclos)
Tiempo medio hasta el mantenimiento
MTTM
MTTM (correctivo o preventivo)
MTTM(c), MTTM(p) tiempo
Tiempo medio hasta la restauración
MTTR
tiempo
Tiempo medio de reparación
MRT
tiempo
Cobertura de averías
FC
sin unidades
Cobertura de reparación
RC
sin unidades
a
tiempo
De acuerdo con la Norma EN 61703 y la Norma IEC 60050-191-2.
B.4 Parámetros de disponibilidad
Tabla B.3 – Ejemplos de parámetros de disponibilidad
Parámetro
Símbolo
Disponibilidad
A
inherente
Ai
operativa
Ao
Unidades
sin unidades
Disponibilidad de flota
FA
Sin unidades
Adherencia al horario
SA
sin unidades o tiempo
En ciertas circunstancias, por ejemplo, con una tasa de fallo constante, tasa de reparación constante y
la ausencia de mantenimiento preventivo (MTTR = MDT), la disponibilidad en régimen permanente se
puede expresar mediante
A
MUT
1
MUT  MDT
con 0 ≤ A ≤ 1 y normalmente con un valor próximo a 1. Su complemento se denomina no disponibilidad U.
U 1 A 
MDT
0
MUT  MDT
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
- 109 -
UNE-EN 50126-1:2018
Dependiendo del tipo de disponibilidad A que haya que considerar, debería decidirse qué fracciones
de MDT son relevantes y, por tanto, tenerse en cuenta para el cálculo. Estas fracciones se han de
definir.
En la Norma EN 61703 se proporcionan directrices detalladas sobre los cálculos para sistemas con
propiedades diferentes y características de reparación diferentes.
El concepto de disponibilidad se ilustra en la figura B.1.
Para un elemento/sistema que está permanentemente en modo de explotación y no se le aplica ningún
tipo de mantenimiento preventivo planificado, se mantiene MUT = MTTF. En este caso, MUT y MTTF
pueden utilizarse indistintamente para calcular la disponibilidad operativa (régimen permanente). Por
tanto, puede expresarse mediante
A
MUT
MTTF

1
MUT  MDT MTTF  MTTR
El tiempo medio de funcionamiento entre fallos (MTBF) se basa normalmente en el tiempo que el
sistema está en uso (en explotación).
Las partes implicadas deberían ponerse de acuerdo sobre la comprensión de todos los términos
utilizados (por ejemplo, la base temporal del MTBF adecuada para la aplicación específica en
consideración o el tipo de retraso que se ha de tener en cuenta). En caso de obligaciones contractuales,
dichos acuerdos deberían estipularse claramente.
Leyenda
MTBF
Tiempo Medio (de Funcionamiento) Entre Fallos
MUT
Tiempo medio operativo (Mean Up Time)
MUFT
Tiempo medio de avería no detectada
MAD
Retraso administrativo medio
MLD
Retraso logístico medio
MTD
Retraso técnico medio
MRT
Tiempo medio de reparación
MTTR
Tiempo medio hasta la restauración (para el mantenimiento correctivo)
NOTA Las definiciones pueden encontrarse en la Norma EN 61703.
Figura B.1 – Concepto de disponibilidad y términos relacionados
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-1:2018
- 110 -
NOTA 1 En la Norma EN 61703 se proporcionan directrices detalladas sobre los cálculos con diferentes propiedades del
sistema y diferentes características de reparación.
NOTA 2 La restauración puede lograrse mediante reparación, sustitución, restauración a un estado inicial u otros medios.
Las definiciones de Disponibilidad de flota (FA) así como de Adherencia al horario (SA) son
normalmente objeto de negociaciones contractuales. Por tanto, esta norma no prevé la elaboración de
ambos parámetros.
B.5 Parámetros de apoyo logístico
Tabla B.4 – Ejemplos de parámetros de apoyo logístico
Parámetro
Símbolo
Unidades
Coste de Explotación y Mantenimiento
O&MC
dinero
Costes de mantenimiento
MC
dinero
Horas Hombre Mantenimiento
MMH
tiempo (horas)
Retraso logístico medio
MLD
tiempo
Retraso administrativo medio
MAD
Tiempo
Tiempo de corrección de averías
–
tiempo
Tiempo medio de reparación
MRT
Tiempo
Tiempo de respuesta
TAT
tiempo
Realización de apoyo a mantenimiento
–
Sin unidades
Empleados de reemplazo
EFR
Número
Probabilidad de existencia de piezas de
repuesto cuando se necesiten
SPS
sin unidades
B.6 Parámetros de seguridad
Tabla B.5 – Ejemplos de parámetros de rendimiento de la seguridad
Parámetro
Símbolo
Unidades
Tasa de peligros
h(t)
1/tiempo, 1/distancia, 1/ciclo
Probabilidad de fallo en el lado equivocado
pWSF
sin unidades
Tiempo activo de retorno a un estado seguro
–
tiempo
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
- 111 -
UNE-EN 50126-1:2018
Anexo C (Informativo)
Calibración de la matriz de riesgos y categorías de aceptación de riesgos
C.1 Generalidades
En el anexo C figuran ejemplos de aplicación de una matriz de riesgos y sus parámetros.
• Para la clasificación de cualquier incidencia, la tabla C.1 y la tabla C.2 proporcionan, en términos
cualitativos, categorías típicas de probabilidad o frecuencia de ocurrencia de incidencias y una
descripción típica de cada categoría para ferrocarriles. En base a estas categorías típicas, el
responsable del servicio ferroviario debe definir los números y la escala numérica a aplicar
(siempre que sean factibles las estimaciones numéricas), de acuerdo con la aplicación en
consideración.
• Entre la tabla C.3 y la tabla C.6 del Anexo C se describen las categorías típicas de gravedad y sus
consecuencias. El responsable del servicio ferroviario debería definir el número de categorías de
gravedad y las consecuencias para cada categoría de gravedad a aplicar, de acuerdo con la
aplicación en consideración.
• En lo que se refiere a la seguridad, la relación entre lesiones y víctimas mortales ("víctima
equivalente", como se define en el apartado 3.19), únicamente con fines predictivos y comparativos,
debería acordarse con el responsable del servicio ferroviario en base al marco legal pertinente.
• Ejemplos de tales relaciones pueden ser:
• una víctima equivalente ≈ 1 víctima mortal ≈ 10 lesiones graves ≈ 100 lesiones menores o
• lesiones graves y víctimas mortales son totalmente equivalentes o
• cualquier otra equivalencia ponderada.
C.2 Frecuencia de las categorías de ocurrencia
Las tablas C.1 y C.2 a continuación ofrecen ejemplos de categorías de frecuencia adaptadas a un uso
particular.
El uso de estos ejemplos particulares no es obligatorio y pueden utilizarse otras clasificaciones.
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-1:2018
- 112 -
Tabla C.1 – Frecuencia de ocurrencia de incidencias peligrosas con ejemplos para su
cuantificación (basada en el tiempo)
Nivel de
frecuencia
Descripción
Ejemplo de ocurrencia
Ejemplo de gama de
equivalente en una
frecuencias basada en
vida útil de 30 años de
un único elemento que
un único elemento que
funciona 24 h/día
funcione 5 000 h/año
Se espera que suceda
Frecuente
Es probable que ocurra con
frecuencia.
La incidencia se experimentará
frecuentemente.
más de una vez en un
período de
aproximadamente 6
semanas
más de 150 veces
Probable
Ocurrirá varias veces.
Se puede esperar que la incidencia
ocurra con frecuencia.
aproximadamente de
una vez cada 6 semanas
a una vez al año
aproximadamente de 15
a 150 veces
Ocasionalmente
Es probable que ocurra varias
veces.
Se puede esperar que la incidencia
ocurra varias veces.
aproximadamente de
una vez al año a una vez
cada 10 años
aproximadamente de 2 a
15 veces
Infrecuente
Es probable que ocurra en algún
momento del ciclo de vida del
sistema. Puede esperarse
razonablemente que ocurra la
incidencia.
aproximadamente una
vez cada 10 años o una
vez cada 1 000 años
puede que una vez como
máximo
Improbable
Es poco probable que ocurra, pero
es posible.
Se puede suponer que la incidencia
puede ocurrir de forma
excepcional.
aproximadamente de
una vez cada 1 000 años
a una vez cada
100 000 años
no se espera que suceda
en el curso de la vida útil
Extremadamente
improbable
Muy improbable que ocurra. Se
puede asumir que la incidencia no
ocurrirá.
una vez en un período de es extremadamente
aproximadamente
improbable que ocurra
100 000 años o más
en el curso de la vida útil
NOTA Los ejemplos que figuran en esta tabla se refieren a un único elemento (sistema/función/componente) y pueden
ajustarse en función del número de sistemas y/o del número de horas de funcionamiento consideradas, por ejemplo.
Cuando la frecuencia es constante, el tiempo medio esperado entre dos incidencias viene dado por el
recíproco de la frecuencia. Para un nivel de frecuencia mayor esta fórmula debería aplicarse tanto a su
límite superior como a su límite inferior.
EJEMPLO 1 Para una tasa de 10-4 h-1:
1/10-4 h-1 = 10 000 h lo que equivale a una frecuencia de incidencias esperada de aproximadamente:
– 1,2 años en caso de 24 h de funcionamiento
– o 2 años en caso de que se suponga un tiempo de funcionamiento de 5 000 h al año.
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
- 113 -
UNE-EN 50126-1:2018
La ocurrencia esperada o el número de incidencias en un período de tiempo se determina mediante el
período de tiempo determinado multiplicado por la tasa o frecuencia de ocurrencia determinada. El
período de tiempo debería reducirse si el tiempo de calendario no es apropiado.
EJEMPLO 2 10-4 h-1  (30 años  5 000 h/año) = 15 → Se espera que la incidencia suceda aproximadamente
15 veces en 30 años si se suponen 5 000 h de funcionamiento al año. 10-4 h-1  (30 años 
5 000 h/año)  10 elementos = 150 → se espera que ocurran aproximadamente 150 fallos entre los
10 elementos durante los 30 años.
El tiempo considerado es un tiempo medio y no necesariamente continuo.
En la tabla C.2 se presenta un enfoque basado en la distancia.
Tabla C.2 – Frecuencia de ocurrencia de incidencias con ejemplos para su cuantificación
(basada en la distancia)
Nivel de frecuencia
Descripción
Ejemplo de gama de frecuencias
F1
Probable que ocurra con frecuencia
más de una vez cada 5000 km por tren
F2
Ocurrirá varias veces
una vez cada 25 000 km por tren
F3
Podría ocurrir a veces
una vez cada 100 000 km por tren
C.3 Categorías de gravedad
Las siguientes tablas dan ejemplos de categorías de gravedad, relacionadas con un uso particular.
Tabla C.3 – Categorías de gravedad (ejemplo relacionado con RAM)
Categoría de gravedad relacionado con RAM
Descripción
Importante
Un fallo que:
(fallo que impide el movimiento)
• impide el movimiento del tren o
• causa un retraso en el servicio superior a un tiempo
especificado
• y/o genera un coste superior a un nivel especificado
Mayor
Un fallo que:
(fallo de servicio)
• impide que el sistema alcance su rendimiento y
• no ocasiona un retraso o un coste superior al umbral
mínimo especificado para un fallo importante
Menor
Un fallo que:
• no impide que un sistema alcance su rendimiento
especificado y
• no cumple los criterios de los fallos importantes o
mayores
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-1:2018
- 114 -
Tabla C.4 – Categorías de gravedad (ejemplo 1 relacionado con RAMS)
Categoría de gravedad
Catastrófico
Consecuencias para las personas o el
entorno
• Afecta a un gran número de personas y
tiene como resultado múltiples víctimas
mortales, y/o
Consecuencias para el
servicio/bienes materiales
Cualquiera de las consecuencias que
se describen a continuación para las
personas o el entorno
• daña al entorno de forma extrema.
Crítico
• Afecta a un número muy pequeño de
personas y resulta en al menos una víctima
mortal, y/o
Pérdida de un sistema importante
• se produce un gran daño al entorno
Marginal
• No hay posibilidad de que se produzcan
víctimas mortales, solo lesiones graves o
leves, y/o
Daños graves en el sistema o
sistemas.
• Daños menores al entorno
Insignificante
• Posible lesión leve
Daños menores al sistema
Tabla C.5 – Categorías de gravedad (ejemplo 2 relacionado con seguridad)
Categoría de gravedad
Consecuencias para las personas o el entorno
S1
Numerosas víctimas equivalentes (probablemente más de 10) o daños extremos al
entorno.
S2
Múltiples muertes equivalentes (probablemente menos de 10) o grandes daños al
entorno.
S3
Una sola víctima o lesiones graves o daños significativos al entorno.
S4
Lesiones leves o daños menores al entorno
S5
Posible lesión leve
Tabla C.6 – Categorías de gravedad económica (ejemplo)
Categoría de gravedad
Consecuencias económicas
SF1
Habrá personas que se vean envueltas en el incidente demandando a la empresa,
supondrá un impacto grave en la imagen pública de la empresa y/o costes
superiores a 1 000 000 €.
SF2
El incidente puede repercutir en la imagen pública de la empresa y/u ocasionar
costes superiores a 100 000 €.
SF3
El incidente no ocasionará costes superiores a 100 000 €.
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
- 115 -
UNE-EN 50126-1:2018
C.4 Categorías de aceptación de riesgos
Las categorías de aceptación de riesgos asignadas a los riesgos identificados permiten su clasificación
para la toma de decisiones. La elección de las categorías de aceptación de riesgos que se utilizarán
debería depender de la elección de los criterios de aceptación de riesgos elegidos y de la decisión a
adoptar. En la tabla C.7 y en la tabla C.8 figuran ejemplos de categorías de aceptación de riesgos:
Tabla C.7 – Categorías de aceptación de riesgos (ejemplo 1 para decisiones binarias)
Categoría de aceptación
de riesgos
Acciones a aplicar
Inaceptable
Es necesaria una mayor reducción del riesgo para que pueda aceptarse
Aceptable
Se acepta el riesgo siempre que se mantenga bajo un control adecuado
Tabla C.8 – Categorías de aceptación de riesgos (ejemplo 2)
Categoría de aceptación
de riesgos
Acciones a aplicar
Intolerable
El riesgo debe eliminarse
No deseable
El riesgo solo debe aceptarse si su reducción es impracticable y previo acuerdo con
los responsables del servicio ferroviario o con la autoridad en materia de seguridad
responsable.
Tolerable
El riesgo puede tolerarse y aceptarse con un control adecuado (por ejemplo,
procedimientos o normas de mantenimiento) y previo acuerdo con los
responsables del servicio ferroviario.
Despreciable
El riesgo es aceptable sin acuerdo previo con los responsables del servicio
ferroviario.
La calibración de la matriz de riesgos debería realizarse en base a los criterios de aceptación de
riesgos, la frecuencia de las categorías de ocurrencia y las categorías de gravedad. En la tabla C.9 se
muestra un ejemplo de una matriz de riesgos calibrada.
Tabla C.9 – Categorías de aceptación de riesgos (ejemplo relacionado con la seguridad)
Frecuencia de
ocurrencia de un
accidente (causado
por un peligro)
Categorías de aceptación del riesgo
Frecuente
No deseable
Intolerable
Intolerable
Intolerable
Probable
Tolerable
No deseable
Intolerable
Intolerable
Ocasional
Tolerable
No deseable
No deseable
Intolerable
Infrecuente
Despreciable
Tolerable
No deseable
No deseable
Improbable
Despreciable
Despreciable
Tolerable
No deseable
Extremadamente
improbable
Despreciable
Despreciable
Despreciable
Tolerable
Insignificante
Marginal
Crítico
Catastrófico
Gravedad de un accidente (causado por un peligro)
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-1:2018
- 116 -
Los Criterios de Aceptación de Riesgos también pueden definirse, ya sea porque lo hagan los
responsables del servicio ferroviario o por requisitos legales, directamente en términos de las Tasas de
Riesgo Tolerable (THR). La THR viene determinada por la gravedad de las consecuencias resultantes
del peligro.
EJEMPLO
Un objetivo de seguridad cuantitativo de referencia (THR) para los criterios de aceptación de
riesgos basados en la estimación explícita de riesgos podría definirse como: En el caso de los
sistemas técnicos en los que un fallo tiene un potencial creíble capaz de desencadenar directamente
a un accidente catastrófico, no es necesario seguir reduciendo el riesgo asociado si se ha
demostrado que la frecuencia del fallo de la función es altamente improbable. Cuando un fallo
funcional tiene potencial creíble capaz de tener directamente consecuencias catastróficas, no es
necesario reducir aún más el riesgo asociado si la tasa de dicho fallo es inferior o igual a 1  10-9 por
hora de funcionamiento.
El objetivo de seguridad cuantitativo expresado como THR para un peligro determinado debería
referirse a funciones elementales específicas sin tener en cuenta su número de casos en todo el
sistema ferroviario. Esto evitará que un sistema técnico determinado con una THR definida y ya
aceptado en una aplicación específica deje de considerarse aceptado cuando se utilice en una
aplicación diferente.
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
- 117 -
UNE-EN 50126-1:2018
Anexo D (Informativo)
Directrices generales sobre la definición del sistema
D.1 Generalidades
El anexo D proporciona directrices generales sobre la definición del sistema.
D.2 Definición del sistema en una aproximación sistemática iterativa
El proceso de evaluación de riesgos se basa en una definición del sistema. En el apartado 7.3 se
enumeran las actividades y entregables necesarios en la fase de definición del sistema.
Se utiliza un método iterativo, aplicable a sistemas jerárquicos, para definir un sistema y sus
subsistemas. El método iterativo es aplicable en diferentes fases del ciclo de vida. Esto podría ocurrir
en fases iniciales del desglose de funciones de un sistema teniendo en cuenta los aspectos de seguridad
o en fases posteriores en las que el método sea aplicable al desglose de funciones o requisitos, por
ejemplo, la asignación de funciones a los subsistemas.
• Los procedimientos detallados para la definición del sistema dependen de la fase del ciclo de vida o
del nivel iterativo del (sub) sistema en estudio.
D.3 Método para definir la estructura de un sistema
D.3.1 Generalidades
Existen varias clases de estructuras de desglose, por ejemplo, la estructura de desglose del sistema o la
estructura de desglose funcional. A efectos de RAMS, el enfoque se centra en un desglose funcional que
agrupa las funciones de forma que puedan un subsistema/producto pueda realizarlas. En este caso, las
funciones del sistema en estudio (incluido el comportamiento tras fallos, cuando se definan) deberían
identificarse y describirse cuando se inicie la definición del sistema.
D.3.2 Lista de funciones
Se debería identificar y describir una lista de funciones que ha de realizar el sistema en estudio cuando
se inicie la definición del sistema. Puede ser una lista preliminar de funciones y/o una especificación
preliminar de los requisitos del sistema dependiendo del nivel de aplicación y del nivel de detalles
conocidos de las funciones.
D.3.3 Desglose funcional
Las funciones identificadas deberían agruparse en base a:
– la contribución a la misma función de nivel superior;
– las limitaciones técnicas identificadas (como subsistemas/productos a reutilizar).
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-1:2018
- 118 -
También se deberían tener en cuenta los principales factores externos del sistema, como:
– las partes o partes interesadas y los límites del sistema;
– las interfaces físicas y funcionales;
– los límites de la evaluación de riesgos.
A continuación, se dan ejemplos típicos de desgloses funcionales de un sistema en el contexto
ferroviario, incluyendo los subsistemas que llevan a cabo la función.
Tabla D.1 – Ejemplos típicos de un desglose funcional
Sistema
Instalaciones fijas
Grupo de desglose
funcional
Proporcionar energía de
tracción a los trenes
Función
Convertir, distribuir y controlar Subestación y puestos de
la energía eléctrica
seccionamiento
Transmitir corriente eléctrica
al vehículo
Material rodante
Control-mando y
Señalización
(Subsistema que realiza
la función)
Sistemas de líneas de
contacto
Gestionar el acceso a la vía Abrir puertas de mamparas de
seguridad en andenes cuando
el tren está presente en la
estación
Sistema de puertas de las
mamparas de seguridad
en andenes
Controlar el acceso a la
estación
Permitir el paso en caso de
evacuación
Sistema de puertas de
acceso
Controlar la velocidad del
tren
Decelerar el tren
Sistema de frenos
Mantener el tren parado en una Sistema de frenos
parada
Controlar el acceso al tren Mantener todas las salidas
cerradas cuando el vehículo
está en movimiento
Sistema de control de
puertas
Control del itinerario
Mantener la posición de los
aparatos de vía
Enclavamiento
Aspecto de la señal de
indicación al maquinista
Enclavamiento
Supervisar la velocidad del Asegurar que el tren no exceda
tren
la velocidad máxima
Control del tren
D.4 Parte/partes interesadas/límites de los sistemas
A la hora de definir y analizar el sistema, deberían tenerse en cuenta las interfaces del sistema y los
límites de la responsabilidad organizativa. Un fallo que ocurre en un sistema puede propagarse a
través de sus interfaces y tener implicaciones que solo otra organización pueda controlar. En tales
casos, los hallazgos deberían comunicarse a la otra organización a su debido tiempo.
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
- 119 -
UNE-EN 50126-1:2018
D.5 Directrices generales sobre el contenido de la definición de un sistema
En el apartado 7.3.2 se definen los aspectos a destacar en el contenido de la definición de un sistema,
incluyendo:
a)
el sistema y el perfil de su misión;
b) los límites del sistema. Ejemplos de interacciones con los límites del sistema incluyen:
–
influencia en los objetos, sistemas y entornos vecinos, incluyendo el personal de explotación, los
pasajeros y el público,
–
definiciones de las condiciones físicas y operativas y del entorno en el que funciona el sistema,
–
descripción de las acciones necesarias del operador. Identificar también a las personas
autorizadas para llevar a cabo estas acciones, indicando la capacitación y cualificaciones
requeridas y la base para dichas acciones, si las hubiera,
–
en caso de que no se incluyan actividades humanas en la descripción, se han de dar las razones.
c)
Requisitos de explotación. Ejemplos de modos de explotación incluyen:
–
modo de explotación normal, anormal/degradado,
desconexión/conexión, etc., y sus interacciones,
–
escenarios de explotación a considerar dentro del análisis, por ejemplo, los efectos de las
operaciones de mantenimiento (¿cómo, con qué frecuencia y quién mantiene el sistema?),
–
requisitos externos, por ejemplo, requisitos de seguridad externos derivados de la política general
de seguridad del responsable del servicio ferroviario, de las consideraciones legales vigentes o de
las normas.
estados
y
transiciones
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
de
UNE-EN 50126-1:2018
- 120 -
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
- 121 -
UNE-EN 50126-1: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
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
Es aplicable toda la
norma.
(Debe aplicarse junto
con la Norma
EN 50126-2).
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-1:2018
- 122 -
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
Capítulo/§/puntos de la Requisitos esenciales (RE)
ETI ENE
de la Directiva 2008/57/CE
Comentarios
1. Requisitos generales
1.1 Seguridad
1.1.1
1.1.3
1.2 Fiabilidad y
disponibilidad
Es aplicable toda la
norma.
(Debe aplicarse junto
con la Norma
EN 50126-2).
4.4. Normas de
explotación
4.5. Normas de
mantenimiento
4.6. Competencias
profesionales
4.7. Condiciones de
seguridad y salud
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
- 123 -
UNE-EN 50126-1: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
Capítulo/§/puntos de la ETI Requisitos esenciales (RE) de
INF
la Directiva 2008/57/CE
Comentarios
1. Requisitos generales
1.1 Seguridad
1.1.1
1.1.3
1.2 Fiabilidad y disponibilidad
Es aplicable toda la
norma.
(Debe aplicarse junto
con la Norma
EN 50126-2).
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
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-1:2018
- 124 -
Bibliografía
EN 614
Safety of machinery. Ergonomic design principles.
EN 60300-3-1
Dependability management. Part 3-1: Application guide. Analysis techniques for
dependability. Guide on methodology (IEC 60300-3-1).
EN 60300-3-2
Dependability management. Part 3-2: Application guide. Collection of dependability
data from the field (IEC 60300-3-2).
IEC 60319
Presentation and specification of reliability data for electronic components.
IEC 60605-2
Equipment reliability testing. Part 2: Design of test cycles.
IEC 60605-3-1
Equipment reliability testing. Part 3: Preferred test conditions. Indoor portable
equipment. Low degree of simulation.
IEC 60605-4
Equipment reliability testing. Part 4: Statistical procedures for exponential
distribution. Point estimates, confidence intervals, prediction intervals and tolerance
intervals.
IEC 60605-6
Equipment reliability testing. Part 6: Tests for the validity and estimation of the
constant failure rate and constant failure intensity.
IEC 60706-1
Guide on maintainability of equipment. Part 1: Sections 1, 2 and 3: Introduction,
requirements and maintainability programme.
EN 60706-2
Maintainability of equipment. Part 2: Maintainability requirements and studies during
the design and development phase (IEC 60706-2).
EN 60706-3
Maintainability of equipment. Part 3: Verification and collection, analysis and
presentation of data (IEC 60706-3).
EN 60706-5
Maintainability of equipment. Part 5: Testability and diagnostic testing (IEC 60706-5).
IEC 60706-6
Guide on maintainability of equipment. Part 6: Section 9: Statistical methods in
maintainability evaluation.
EN 60812
Analysis techniques for system reliability. Procedures for failure mode and effects
analysis (FMEA) (IEC 60812).
EN 61014
Programmes for reliability growth (IEC 61014).
EN 61025
Fault tree analysis (FTA) (IEC 61025).
IEC 61070
Compliance test procedures for steady-state availability.
EN 61078
Analysis techniques for dependability. Reliability block diagram and boolean methods
(IEC 61078).
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
- 125 -
UNE-EN 50126-1:2018
IEC 61123
Reliability testing. Compliance test plans for success ratio.
EN 61160
Design review (IEC 61160).
EN 61165
Application of Markov techniques (IEC 61165).
EN 61508
Functional safety of electrical/electronic/programmable electronic safety-related
systems (IEC 61508).
EN 61703
Mathematical expressions for reliability,
maintenance support terms (IEC 61703).
EN 61709
Electric components. Reliability. Reference conditions for failure rates and stress
models for conversion (IEC 61709).
IEC/TR 62380
Reliability data handbook. Universal model for reliability prediction of electronics
components, PCBs and equipment.
EN ISO 9001
Quality management systems. Requirements (ISO 9001).
availability,
maintainability
ISO/IEC Guide Safety aspects. Guidelines for their inclusion in standards.
51
VDI 4006
Human reliability. Methods for event analysis regarding human behaviour.
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
and
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