Análisis del Método RBD para la

Determinación de la PFD* de los Elementos

de una SIF (IEC 61508)
(*Probabilidad de Falla en Demanda)

Resumen
Dentro del marco de las actividades del Ciclo de Vida de Seguridad de un Sistema
Instrumentado de Seguridad, existe la necesidad de conocer el desempeño, en
términos del Nivel de Integridad de la Seguridad (Safety Integrity Level SIL), de cada
Función Instrumentada de Seguridad (SIF) que lo conforman. Por lo tanto, es
necesario cuantificar la falla aleatoria de la función tomando en cuenta todos y cada
uno de los elementos o subsistemas que están presentes en la SIF. En el presente
post, se muestra como cuantificar la Probabilidad de Falla en Demanda Promedio (

) de una SIF, en modo bajo demanda (Cuando se requiere su acción), realizando

un análisis del método RBD (Reliability Block Diagram), como lo hace estándar IEC-
61508 Parte 6.

1.   Introducción
Cuando los procesos o sistemas críticos que se utilizan en la industria nuclear,
química, petróleos, etc no son apropiadamente controlados o mantenidos pueden
dejar de funcionar y, en algunos casos, llevar al Proceso Bajo Control (EUC) a un
riesgo significativo para la seguridad de personas, medio ambiente y financiero. Los
Sistemas Instrumentados de Seguridad o SIS, como se les conoce, son sistemas
diseñados para reducir el riesgo del proceso cuando existen desviaciones de sus
variables o malfuncionamiento de algún equipo o instrumento.
El hardware de un SIS está compuesto principalmente por tres subsistemas,
subsistema de sensado, subsistema de resolvedor lógico y subsistema de actuación;
como se muestra en la figura 1. El subsistema de sensado monitorea el proceso
crítico, examinando condiciones potencialmente inseguras; el resolvedor lógico

1
interpreta las entradas del subsistema de sensado y ejecuta determinadas acciones
mediante el subsistema de actuación.
El estándar IEC-61508, publicado en el año 1997 y actualizado en 2010, ha sido
adoptado por muchos países como una norma de carácter nacional. En este se
muestran 2 conceptos muy importantes: el Ciclo de Vida de Seguridad y el Nivel de
Integridad de la Seguridad (Safety Integrity Level, SIL). Como procedimiento dentro
del Ciclo de Vida de Seguridad es necesario realizar la cuantificación de la falla
aleatoria que, comúnmente, se conoce como verificación del SIL, de cada SIF que
conforman al SIS, de tal manera de confirmar que la Probabilidad de Falla en

Demanda promedio ( ) del hardware diseñado cumple con el Factor de

Reducción de Riesgo requerido por el proceso. En caso de no cumplir este
requerimiento es necesario realizar una modificación a dicho hardware hasta cumplir
con la Reducción de Riesgos necesaria. El proceso de demostración que la SIF
cumple con los requisitos de la aplicación, toma en cuenta, además, las restricciones
de hardware definidas en la norma IEC-61508 y IEC-61511 y la Capacidad
Sistemática del hardware utilizado.
 

Fig. 1 Hardware de Sistema Instrumentado de Seguridad

El proceso de verificación del SIL puede ser abordado mediante diferentes
metodologías, todas basadas en técnicas de análisis probabilístico y entre las más
conocidas están: Análisis de Árbol de Fallas (FTA), Análisis Modos de Falla y Eventos

2
(FMEA), Diagrama de Bloques de Confiabilidad (RBD), Análisis de Markov, técnicas
mixtas, etc. El uso de cada técnica tiene sus ventajas y desventajas.

2.   Probabilidad de Falla en Demanda (PFD)

Es una medida que está definida como la probabilidad de que la SIF no pueda cumplir
con la intención para la cual fue diseñada, en otras palabras, es la probabilidad con la
cual la SIF es incapaz de desempeñar su función de seguridad; lo que significa que la
SIF esta inhabilitada para responder a una demanda y no podrá iniciar ninguna acción
de seguridad. La PFD indica un valor instantáneo, para su uso en seguridad funcional

es necesario expresar como   la cual indica un valor promedio sobre el intervalo
de prueba de la SIF

; (1)

Hay que considerar que la   es una función de la tasa de

fallas  , la tasa de reparación  , el Intervalo de prueba  ,

las fallas de causa común  , entre otros.
Para satisfacer los requerimientos dados en la Especificaciones de los
Requerimientos de la Seguridad (SRS) de la SIF con un SIL objetivo obtenido del

análisis de riesgo del proceso, la   de la SIF diseñada debe ser menor al valor
límite indicado en la tabla 1, según sea el caso.

Tabla 1. SIL y   según IEC-61508.

Probabilidad de
Nivel de Falla en Reducción de
Integridad de Demanda Riesgo
Seguridad (SIL) Promedio Requerida
(PFDavg) (FRR)
4 ≥10−5 a <10−4 >10.000 a

3
 Probabilidad de
Nivel de Falla en Reducción de
Integridad de Demanda Riesgo
Seguridad (SIL) Promedio Requerida
(PFDavg) (FRR)
≤100.000
≥10−4 a <10−3 >1.000 a
3 ≤10.000
≥10−3 a <10−2
2 >100 a ≤1.000
≥10−2 a <10−1
1 >10 a ≤100
 

3.   Diagrama de Bloques de Confiabilidad (RBD)

Es una técnica gráfica de análisis, la cual expresa como está conectado un sistema y
el número de componentes de acuerdo a una relación lógica de confiabilidad.
Los componentes conectados en serie representan una conexión lógica “and” y los
conectados en paralelo son representados mediante la conexión “or”, mientras que, la
combinación de componentes en serie y paralelo representa lógica de votación. Un
esquema RBD tiene un orden de análisis, siempre va de izquierda a derecha, y desde
el nodo más a la izquierda hacia el nodo más a la derecha se presentarán las
trayectorias o rutas para una operación exitosa del sistema (representa una medida
de éxito). Cuando un componente falla, este cortará la conexión o ruta
correspondiente, a medida que ocurren las fallas en los componentes, el sistema
seguirá operando o funcionando hasta que no exista una ruta o vía válida desde el
nodo más a la izquierda al nodo más a la derecha y, la probabilidad de falla del
sistema en estudio se puede calcular o determinar de acuerdo a principios
probabilísticos; por ejemplo: sea un subsistema con votación 1oo2, esto significa que
dispone de 2 canales diferentes con sus propios componentes, es decir,
independientes, y se requiere que con 1 canal disponible todavía puede ser confiable

4
y cumplir con su intención de diseño; sin embargo, está claro que podría darse una
falla de causa común que afectaría a ambos componentes y en esa circunstancia, el
sistema  deja de ser confiable, por lo que, ante una demanda él no podrá llevar al
proceso a modo seguro, tal esquema se muestra en la siguiente figura:

Fig. 2 RBD para un esquema de votación 1oo2 de sensores

Para el presente documento se consideran las siguientes suposiciones para el uso del
Enfoque RBD:

a)  La   resultante de un subsistema es menor que 10 -1 (Modo Bajo

Demanda) y también la PFH es menor a 10 -5 (Modo Alta Demanda y Modo
Continuo).
b)  La tasa de falla y reparación de los componentes se consideran constantes
dentro del tiempo de vida del sistema.
c)  La tasa de falla de hardware utilizado como información para el cálculo se
considera para subsistemas con canales simples.
d)  Todos los canales en un grupo de votación tienen la misma tasa de falla y la
misma tasa de cobertura de diagnóstico.
e)   La tasa de falla de hardware total de un canal en un subsistema es la suma
de la tasa de fallas peligrosas y la tasa de fallas seguras y se asume iguales.
f)  La prueba o test y reparación para cada función de seguridad es completa
(perfecta). Esto significa que todas las fallas que permanezcan sin detectar
son detectadas por la prueba o test.
g)   El intervalo de prueba es por lo menos una orden de magnitud mayor que el
intervalo de test de diagnóstico.
h)   No se considera el estudio del efecto de la tasa de demanda y el intervalo
esperado entre la demanda.

5
 i)    Para cada subsistema hay un único intervalo de prueba y un tiempo medio
para la restauración.
j)   Se considera que se encuentra disponibles múltiples grupos de reparación
para trabajar en todas las fallas conocidas.
k)  El intervalo esperado entre las demandas es por lo menos un orden de
magnitud mayor que el tiempo medio para la reparación.

3.1 Autodiagnóstico, Fracción de Falla Segura y Tiempo Medio Improductivo

(MDT)
Hoy en día, muchos equipos pueden detectar fallas por sí mismos mediante el
denominado diagnóstico; esta característica o capacidad en un equipo se denomina
Cobertura de Diagnóstico (DC) y en ningún caso puede detectarse la totalidad de las
fallas, es decir, que el DC nunca llega al 100%. Ahora la tasa de falla total de un

equipamiento  , tal como lo muestra la figura, se divide en fallas seguras   y fallas

peligrosas  , las mismas se dividen en seguras detectadas  , seguras no

detectadas  , así como, en peligrosas detectadas   y peligrosas no

detectadas  Las tasas de falla seguras son justamente las que llevan a modo
seguro; por otro lado, las fallas peligrosas pueden detectarse mediante diagnóstico y
justamente coincide con el criterio de la cobertura de diagnóstico definido
anteriormente. Por lo tanto, las fallas peligrosas no detectadas son aquellas que
debemos estudiar y determinar y este valor es el que nos indica cuán confiable es el
equipo para las aplicaciones de seguridad. La norma IEC-61508 introduce el término
fracción de falla segura SFF definido como:

;
(2)
para identificar las características de confiabilidad de un determinado dispositivo que
será utilizado de una Función Instrumentada de Seguridad.

6
 Fig.3 División de la tasa de fallas total

La probabilidad de falla en demanda está relacionada con las fallas

peligrosas   que evitan que el SIS funcione cuando se precise que así lo
haga; es decir, ante una demanda. En el análisis se puede considerar que para cada
SIF existe una prueba de funcionamiento periódica en un tiempo Ti y también existe
una reparación perfecta, por lo que todas las fallas no detectadas se descubren
mediante una prueba periódica de la SIF. Cuando se produce una falla, se presupone
que en promedio ocurre en el punto intermedio del intervalo de prueba periódica; en
otras palabras, la falla sigue sin detectarse durante el 50% del período de prueba.
Tanto para fallas peligrosas no detectadas y peligrosas detectadas, el tiempo medio
improductivo o MDT depende del intervalo de prueba Ti, el tiempo medio de
reparación MTR y del tiempo medio hasta el restablecimiento MTTR.

4.   Cálculo de la PFDavg mediante RBD

4.1 Arquitectura 1oo1

Esta arquitectura consiste de un solo canal, sin embargo, como nuestro análisis está
centrado al estudio de las fallas peligrosas y estas se dividen en fallas peligrosas
detectadas y fallas peligrosas no detectadas, al tener diferentes tasas de falla cada
una es necesario agrupar estas fallas en una arquitectura en serie, tal como lo

muestra la figura, donde   representa el bloque de fallas peligrosas no detectadas

(las más peligrosas) y   las fallas peligrosas detectadas. Ambas dan como resultado

7
el denominado tiempo medio improductivo   cuya tasa de falla es   y es posible
calcularlo sumando los tiempos medios improductivos en directa proporción respecto
a la contribución de la probabilidad de falla del canal, es decir:

;
(3)

;
(4)

Fig.4 Arquitectura RBD para un esquema 1oo1

Ejemplo:

Sea un elemento del cual se desea obtener la   para diferentes valores de la
cobertura de diagnóstico DC y se conoce que la tasa de

fallas peligrosa es  , el tiempo de reparación es igual al tiempo de

restablecimiento  .

8
Mediante el uso de la ecuación 4, se puede observar además que la   aumenta

conforme aumenta el Intervalo de prueba  y reduce conforme aumenta el porcentaje

de la Cobertura de Diagnostico.
4.2 Arquitectura 1oo2
Esta arquitectura consiste en dos elementos conectados en paralelo, de tal manera
que cualquier canal puede ejecutar la función de seguridad, por lo tanto, debería
existir una falla peligrosa en ambos canales antes de que la función de seguridad falle
bajo una demanda. Se supone que cualquier test de diagnóstico solo reportará las
fallas encontradas y no cambiará a ningún estado su salida ni la votación

especificada. La figura muestra el RBD para dicha arquitectura donde   ,  

pertenecen al equipamiento o componente 1 y ,  al equipamiento o componente

2.

Fig. 5 Arquitectura RBD para un esquema 1oo2

Por otro lado, el RBD contiene un bloque en serie adicional que representa las fallas
de causa común considerando que los equipos en paralelo son similares, este bloque

denota la fracción de fallas no detectadas que tienen causa común  . Ahora, para el

9
caso de fallas detectadas por diagnóstico de causa común  . Estos valores son
fracciones que se consideran igual entre 5% al 10% del total de fallas peligrosas del
equipamiento.
El tiempo medio improductivo MDT para esta arquitectura está definida como:

;
(5)

Donde   es el tiempo improductivo de cada elemento o equipamiento y se nota que

con esta arquitectura el tiempo de parada del conjunto   se reduce a la mitad

de  .
Cuando un canal o elemento falla de forma peligrosa, el conjunto pasa a un estado de
operación degradada y, aun así, puede desempeñar la función de seguridad
especificada ante una demanda con el que queda operando, si este segundo
elemento falla de forma peligrosa entonces todo el grupo falla y la función no podrá
ejecutar la función de seguridad.

La  , según indica IEC-61508 Parte 6, considerando efectos de fallas de causa

común es:

;
(6)
Ejemplo:

El resultado de la tabla nos indica un resultado similar al anterior, sin embargo, se

puede ver la   se reduce notablemente cuando se utiliza arquitectura con
votación.

10
4.3 Arquitectura 2oo2
Esta arquitectura consiste en dos elementos conectados en serie, por lo tanto, ambos
canales son necesarios para ejecutar la función de salida ante una demanda. La

figura muestra el RBD para la arquitectura 2oo2; donde, la   está dada por:

;        (7)

Fig. 6 Arquitectura RBD para un esquema 2oo2

Ejemplo

Esta arquitectura no dispone mejor   que la que tiene 1oo1.

4.4 Arquitectura 2oo3
Esta arquitectura consiste en tres elementos conectados en paralelo con un arreglo
de votación mayoritario para la salida de la señal, la misma no cambiará si solo un
elemento presenta un resultado diferente o en desacuerdo con los otros dos
elementos. Sin embargo, en temas de seguridad, para que la función esté disponible,
con la falla de un elemento la función puede permitir la activación de la salida de
votación pasando a modo de operación degradado, si existiera una segunda falla
entonces esta arquitectura no puede ejecutar la función de salida; por lo tanto, no
estará disponible la SIF.

11
La figura 7 y 8 muestran la arquitectura para una votación 2oo3.

Fig. 7 Arquitectura RBD para un esquema 2oo3

Fig. 8 Arquitectura RBD para un esquema 2oo3

 

;                       (8)

;                      (9)

12
 ;      
(10)
Ejemplo

Vemos como la   para esta arquitectura es menor que la 1oo2.

5.   Conclusiones
Hemos observado como la metodología RBD puede ser aplicada para la

determinación cuantitativa de la   de los elementos que participan en una SIF;
aun cuando se encuentran en configuración de votación.
El modelo de RBD refleja la estructura de confiabilidad del sistema o subsistema en
estudio; es intuitivo y relativamente fácil de desarrollar.
Un siguiente paso es abordar el estudio de arquitecturas de votación como 1oo3,
2oo4; y cuando disponen de diagnóstico como 1oo2D, oo3D.

6.   Bibliografía
Guo H., Yang X. “A simple reliability block diagram
method for Safety integrity verification”. Reliability Engineering and
[1] Systems Safety 92 (2007). Elsevier.
Creus A., “Fiabilidad y Seguridad”, Marcombo Ediciones
[2] técnicas, 2da Edición 2005
Fernandez I. et al. “Sistemas Instrumentados de
[3] Seguridad y análisis SIL”, ISA Sección España Diaz de Santos. 2012
[4] Magnetrol. “Understanding Safety Integrity level”

13
 Special application Series.
IEC 61508. “Functional safety of electrical/electronic/programable
electronic safety-related systems. Part 6. Guideline on the Applications of
[5] IEC-61508-2 and IEC-61508-3.
IEC 61511. “Functional safety” safety instrumented systems
[6] for process industry sector, Part 1, part 2 and Part 3.
 
 

Reducciones de Arquitectura Según IEC 61508

Para determinar el SIL que puede alcanzar una Función Instrumentada de Seguridad
(SIF) que opera en modo bajo demanda, hay que tomar en cuenta tres variables:
 La Probabilidad de falla en Demanda Promedio (PFD avg: Probability of
Failre on Demand Average).
 La Tolerancia de Falla por Hardware (HFT: Hardware Fault Tolerance) y;
 La Capacidad Sistemática (SC: Sistematic Capability).
En las publicaciones anteriores, se explicó cómo se determina la PFD avg para
arquitecturas 1oo1 y 1oo2 y, por lo tanto, qué SIL puede alcanzar una SIF por esta
vía; ahora trataremos de las restricciones que impone el HFT sobre el SIL alcanzado
de acuerdo con la norma IEC 61508.
La norma IEC 61508 establece el SIL más alto que se le puede otorgar a una SIF de
acuerdo con la arquitectura de votación de sus subsistemas mediante dos
definiciones del HFT o rutas:
 La Ruta 1H: Basada en la Fracción de Falla Segura de los
componentes, y;
 La Ruta 2H: Basada en la confiabilidad de los componentes (probado en
uso).
En este post, nos enfocaremos en la Ruta 1H. Según la Ruta 1H, la relación de HFT y
SIL viene definida por el SFF del elemento o subsistema. En las tablas siguientes
definen esta relación en función del tipo de dispositivo A (simple) o B (complejo).
Tabla 1. Tolerancia de Falla por Hardware. Dispositivos Tipo A. IEC 61508-2010
SFF Tolerancia de falla de Hardware (Hardware Fault

14
 Tolerance)
0 1 2
< 60 % SIL 1 SIL 2 SIL 3
60 a 90 % SIL 2 SIL 3 SIL 4
90 % a 99 % SIL 3 SIL 4 SIL 4
≥ 99 % SIL 3 SIL 4 SIL 4
Tabla 2. Tolerancia de Falla por Hardware. Dispositivos Tipo B. IEC 61508-2010
Tolerancia de falla de Hardware (Hardware Fault
Tolerance)
SFF 0 1 2
< 60 % No se permite SIL 1 SIL 2
60 a 90 % SIL 1 SIL 2 SIL 3
90 % a 99 % SIL 2 SIL 3 SIL 4
≥ 99 % SIL 3 SIL 4 SIL 4
 El SFF de un elemento dado, está establecido por la relación de las tasas de fallas
que son seguras (pueden ser detectadas), y viene dada por la ecuación 1.
Ecuación 1:

Siendo:

 : Tasa de Falla Segura

: Tasa de Falla Segura Detectada

 : Tasa de Falla Total

 Una vez que se tiene el máximo SIL permitido para un elemento, de acuerdo con la
Ruta 1H de la norma IEC 61508, se puede dar el caso que se tengan elementos en
serie o paralelo con distintos SIL permitidos, de ser así, para determinar el máximo
SIL permitido para el subsistema (arreglo) se deben seguir unas reglas (IEC 61508-2:
7.4.4.2.3 y 7.4.4.2.4):

15
  Si se tienen elementos en serie, el máximo SIL que se puede reclamar
para ese subsistema es el determinado por el de menor SIL. (Ver
ejemplo 1)
 Si se tienen elementos en paralelo, el máximo SIL que se puede
reclamar es el del mayor más uno (1). (Ver ejemplo 2)
Ejemplo 1:
Si se tienen 3 elementos en serie: A, B y C, y de acuerdo con las tablas de la norma
IEC 61508 para el HFT, el máximo SIL permitido de cada elemento es SIL 1, 3 y 1
respectivamente, como se ve en la Figura 1, el máximo SIL permitido para este tipo
de subsistema es de SIL 1, independientemente de la PFD avg alcanzada, como se
muestra en la Figura 2.

Figura 1. Arquitectura en Serie.

Figura 2. Arquitectura en Serie. Restringido por Arquitectura.

Ejemplo 2:
Se tienen dos elementos A y B como se observa en la Figura 3, con máximos SIL
permitido de SIL 1 cada uno, si están en paralelo (arquitectura 1oo2), pueden
alcanzar hasta un SIL 2.

Figura 3. Arquitectura en Paralelo

16
 Figura 4. Arquitectura en Paralelo.
La Ruta 2H, y las restricciones de capacidad sistemática (Sistematic Capability), serán
tratadas en el próximo Post.

Pon a prueba tus conocimientos:

Trabajando en Seguridad Funcional: La

gestión como herramienta para evitar las
fallas sistemáticas
En los últimos años muchos procesos industriales han sido automatizados para
aumentar la producción, mejorar la calidad de los productos y reducir el potencial de
error humano. Sin embargo, las nuevas tecnologías, a pesar de disminuir los
requerimientos de mano de obra, exigen mayores esfuerzos para un buen
funcionamiento. Cuanto más automatizados son los equipos, más fallas sistemáticas
pudieran conducirlos a operaciones inadecuadas. Sistemas mal implementados o
mantenidos pueden dar lugar a eventos peligrosos que nos pudieran afectar a todos.

17
Para diseñar, mantener y operar, de forma adecuada, un Sistema Instrumentado de
Seguridad (SIS), que es hoy día uno de los principales sistemas automatizados
utilizados en la seguridad, se deben tomar en cuenta todas las causas que pudieran
afectar su funcionamiento. Una adecuada gestión de la seguridad funcional que
permita controlar las fallas aleatorias (asociadas a la degradación del hardware) y
evitar las fallas sistemáticas (usualmente asociadas al factor humano) es esencial.
Esto implica el uso de materiales de primera, procesos de diseño y fabricación de alta
calidad, es decir, hacer un diseño que sea lo suficientemente robusto para soportar
cualquier fuente de estrés y generar nuevas formas de trabajo que permitan realizar
las tareas de diseño, fabricación, instalación, mantenimiento y operación en forma
sistemática.
La seguridad funcional se ha beneficiado de los avances y esfuerzos realizados por
fabricantes en tratar de generar productos certificados que den cierto nivel de garantía
sobre el grado de integridad que sus productos pueden ofrecer y de la comprensión
de los usuarios finales sobre la importancia de definir un nivel de integridad y diseñar
en función a éste. Pero, hacer el trabajo relacionado con la seguridad funcional con un
enfoque sistemático y fomentar una cultura de seguridad funcional que nos ayude a
evitar las fallas sistemáticas es sin duda nuestro siguiente desafío. Para tener una
idea del desafío que debemos enfrentar, podemos citar a Angel Casal en su
publicación “SIS Pitfalls, Major Accidents and Lessons Learned”, quien nos indica que
desde 1987 al 2012 el 90% de los accidentes mayores ocurridos en la industria de
procesos son debidos a fallas sistemáticas.
La normativa internacional de seguridad funcional IEC 61508, su normativa específica
para la industria de los procesos IEC 61511 y su equivalente ISA 84.00.01 nos dan
una guía y unos pasos (en un orden especifico) que nos permite asegurar que estos
sistemas están siendo manejados bajo un enfoque sistemático y holístico en cuanto a
su diseño, operación y mantenimiento y que el riesgo se mantiene en los niveles
determinados como tolerables.
Ahora bien, si sabemos que adoptar estos estándares nos ayuda a combatir las fallas
que pueden presentar estos sistemas, ¿Por qué no implementarlos si son
considerados como mejores prácticas en muchas partes del mundo?

18
Cuando hablamos de gestión de la seguridad funcional muchos de los elementos a
considerar son muy parecidos a los utilizados en gestión de proyectos. Una buena
gestión de la seguridad funcional debe definir las actividades que serán desarrolladas
(es decir cada paso del Ciclo de Vida de Seguridad), debe indicar cuando serán
desarrolladas estas actividades y que herramientas serán utilizadas. Además, debe
definir los recursos y las personas que serán responsables. En general, debemos
considerar:
 Una planificación de las actividades que serán realizadas en cada fase
del Ciclo de Vida de Seguridad, con la descripción de los requisitos de
cada una, incluyendo las actividades de verificación y evaluación
(assessment). Esto es, esencialmente, el plan de ejecución que se
aplicará al proyecto, en función del alcance que debamos cubrir.
 La definición de la organización donde se designen los responsables y
las personas que formarán parte del equipo de trabajo. Se debe
garantizar que las personas sean competentes para realizar cada una
de las tareas que le fueron asignadas en cada fase y se debe asegurar
que cada uno de ellos tenga las competencias requeridas según el rol
que deban desempeñar.
 La definición de las guías y procedimientos a utilizar, es decir, debemos
definir cómo deben ser desarrolladas cada una de las actividades y que
herramientas serán utilizadas.
 La documentación que necesitamos para realizar un trabajo, la
información que debe ser generada y la forma en la que debe ser
manejada para que sea utilizada apropiadamente a lo largo de la vida
útil de los sistemas.
 Las evaluaciones periódicas que nos permitan comprobar que los
riesgos están siendo mantenidos en niveles tolerables y que los
procedimientos de trabajo están siendo utilizados en forma apropiada
por personal capacitado.
La siguiente figura nos muestra de forma gráfica todos los elementos que hemos
mencionado hasta ahora,

19
 Figura
1. Gestión de la Seguridad Funcional
Como vemos, adoptar una buena práctica recomendada para sistemas automatizados
(o instrumentados) no es algo que se aleja de nuestra realidad al gestionar un
proyecto, solo requiere de un profundo compromiso con la mejora continua.
Implementar este tipo de normativas nos permite identificar mejoras en materia de
seguridad que se adapten a nuestra forma de trabajo, puesto que, al estar basadas en
desempeño, el usuario es libre de desarrollar diseños y soluciones que demuestren
cumplimiento dentro del esquema de trabajo establecido por la normativa.
Así que, luego de manejar toda esta información ¿por qué no darle la importancia
que se merece una buena gestión de seguridad funcional, si sabemos que al no
implementarla los sistemas se degradan y aumentan los riesgos?

20
 ¿Qué es y cómo se logra la integridad de
la Seguridad Funcional?
En primera instancia desglosemos el concepto en un par de términos básicos.
Integridad: De integro; “que está completo y que no carece de ninguna de sus partes“
(DRAE) y Seguridad (Safety): “Ausencia de riesgo inaceptable” (IEC61508:2010 |
3.1.11) o “Ausencia de riesgo no tolerable” (61511:2016 | 3.2.64).

Para diseñar, mantener y operar un sistema relacionado con la seguridad, como un

Sistema Instrumentado de Seguridad (SIS), que pueda ofrecer seguridad en una
forma íntegra, es decir completa, deben tomarse en cuenta todos los factores que
puedan afectarla, esto es, se deben tomar en cuenta todas las causas que puedan
hacer que el SIS se vea inhabilitado de poder ejercer, en forma adecuada, la función
para la cual ha sido construido.

Así que, para que un SIS pueda alcanzar la integridad de la seguridad para la cual
está diseñado, deben ser controladas o evitadas todas las fallas
aleatorias (normalmente asociadas al hardware) y todas las fallas
sistemáticas (normalmente asociadas con el software y el diseño). El manejo de
fallas, tanto aleatorias como sistemáticas, fue previsto por quienes desarrollaron las
normativas basadas en desempeño, creando disposiciones que permitan gestionar en
forma efectiva ambos tipos de fallas.

Esto nos lleva a por lo menos dos conceptos más:

Primero, la Integridad de Seguridad del Hardware, que es entendida como “la parte

de la integridad de seguridad del SIS relativa a fallas aleatorias de hardware en un
modo de falla peligrosa” (61511:2016 | 3.2.26). Para lograr la Integridad de
Seguridad del Hardware, se han establecidos los Niveles de Integridad de
Seguridad conocidos como SIL (Safety Integrity Level), como una medida de
reconocer que ningún sistema es capaz de ofrecer un 100% de integridad de

21
seguridad (un sistema infalible), pero sí nos podemos acercar en buena medida a ese
valor, en función de la reducción de riesgo que es capaz de ofrecer cada aplicación
(SIL1, SIL2…etc.).

Segundo, la Integridad de Seguridad Sistemática entendida como “la parte de la

integridad de seguridad del SIS relativa a fallas sistemáticas en un modo de falla
peligrosa” (61511:2016 | 3.2.26). Estos tipos de fallas son normalmente difíciles de
establecer o cuantificar y en ocasiones solo se pueden considerar cualitativamente,
por esta razón, surge la necesidad de hacer un enfoque sistemático como el del Ciclo
de Vida de Seguridad. Para lograr la Integridad de Seguridad Sistemática se
deben seguir los lineamientos del Ciclo de Vida de Seguridad, que para el usuario
final y el consultor/integrador son mostrados en la IEC-61511 y para los fabricantes en
la IEC-61508, y es expresada a través de la Capacidad Sistemática (SC: Systematic
Capability) del equipo ofrecido, como señal de que el fabricante ha cumplido con su
parte.

Como vemos, no hay forma de lograr la Integridad de la Seguridad si no ponemos

atención tanto a la gestión de las fallas aleatorias, como a las fallas sistemáticas como
un todo.

Adicionalmente, miremos las referencias originales de las normativas:

Integridad de Seguridad: Probabilidad media de que un sistema instrumentado de

seguridad realice satisfactoriamente las funciones instrumentadas de seguridad en
todas las condiciones establecidas dentro de un periodo de tiempo establecido. (IEC
61511 2003 | 3.2.73)

Integridad de Seguridad: Habilidad del SIS para realizar una SIF según sea
especificada y cuando sea requerida. (IEC 61511 2016 | 3.2.68)

22
Integridad de Seguridad: Probabilidad de que un sistema E/E/PE relacionado con la
seguridad ejecute de forma satisfactoria las funciones de seguridad requeridas en
todas las condiciones especificadas en un periodo de tiempo especificado. (IEC
61508 2010 | 3.5.4)
 

PONGA A PRUEBAS SUS CONOCIMIENTOS.

 
           1. La integridad de la Seguridad del SIS está relacionada a:
a.     Las fallas del Hardware y su PFD
b.     Las Fallas del Software
c.     Las Fallas Aleatorias y las Fallas Sistemáticas 
 
2. La integridad de la Seguridad Sistemática es gestionada a través de:
a.     Del cálculo del SIL
b.     Del Ciclo de Vida de Seguridad
c.     Del uso de Capas de protección

Responda las preguntas de comprobación AQUÍ

Comencemos por el principio: ¿Qué es Seguridad

Funcional?

Existen un buen número de referencias respecto al concepto Seguridad

Funcional y para establecer el contexto podemos citar algunos:

Para la norma IEC 61508:2010 la Seguridad Funcional es:

“Parte de la seguridad global que se refiere al EUC y al sistema de control
del EUC que depende del funcionamiento correcto de los sistemas E/E/PE

23
relacionados con la seguridad y de otras medidas de reducción del riesgo”
(3.1.12).

Mientras que para la norma IEC 61511:2016 es:

“Parte de la seguridad general relativa al proceso y alBPCS que depende del correcto
funcionamiento del SIS y de otras capas de protección” (3.2.23).

Otras fuentes son:

HSE: “… es la parte de la seguridad global de las instalaciones que depende del
correcto funcionamiento de los sistemas relacionados con la seguridad y otras
medidas de reducción de riesgos como los sistemas instrumentados de seguridad
(SIS), los sistemas de alarma y los sistemas básicos de control de procesos (BPCS)”

TÜV Rheinland: “… es la parte de la seguridad global que depende de que un

sistema o equipo funcione correctamente en respuesta a sus entradas” …… “..es la
detección de una condición potencialmente peligrosa que resulta en la activación de
un dispositivo o mecanismo protector o correctivo para evitar que se produzcan
eventos peligrosos o proporcionar mitigación para reducir las consecuencias del
evento peligroso”

TÜV SÜD: “…. es la parte de la seguridad general de un sistema o equipo que

depende del sistema o equipo que funcione correctamente en respuesta a sus
entradas, incluyendo la gestión segura de errores probables del operador, fallas de
hardware y software y cambios ambientales”

UL: “… es la parte crítica de la seguridad general de un sistema o producto que

depende de la ejecución correcta de comandos y funciones específicos”

CSA: “…. se describe como la representación de productos o sistemas cuya falla en

el funcionamiento confiable puede dañar a las personas, la propiedad o el medio
ambiente”

24
David Smith: “Se utiliza para referirse a la fiabilidad (conocida como integridad en el
mundo de la seguridad) de los equipos relacionados con la seguridad. En otras
palabras, se refiere a la probabilidad de que funcione correctamente, de ahí la palabra
funcional”

Podríamos inclusive nombrar a Wikipedia, que publica que: “…se refiere a

la parte de la seguridad global de un sistema consistente en que sus
componentes o subsistemas eléctricos, electrónicos y programables con
implicaciones en materia de seguridad respondan de forma adecuada ante
cualquier estímulo externo, incluyendo errores humanos, fallos de hardware
o cambios en su entorno”
Ahora bien, formarse un concepto un poco más simple creo que se requiere
del auxilio de algunos otros conceptos:

El primero de ellos es el concepto de Seguridad (Safety), que según la

norma IEC 61508:2010 es “Ausencia de riesgo inaceptable” (3.1.11) y según
IEC 61511:2016 es “Ausencia de riesgo no tolerable” (3.2.64).

Adicionalmente, creo necesario estudiar el concepto de Función de

Seguridad, que según la norma IEC61508:2010 es “Función a realizar por
un sistema E/E/PE relacionado con la seguridad o por otras medidas de
reducción del riesgo, que está destinada a lograr o mantener un estado
seguro del EUC con respecto a un evento peligroso específico” (3.5.1) y
según IEC 61511:2016 es “Función a ser implementada por una o
más capas de protección, la cual está destinada a lograr o mantener un
estado seguro para el proceso, con respecto a un evento peligroso
específico” (3.2.65).

25
Y estos a su vez no llevan a los conceptos de sistema E/E/PE relacionado
con la seguridad (IEC 61508) y otras medidas de reducción del riesgo (IEC
61508) o capa de protección (IEC 61511).
Sistema relacionado con la seguridad: “Un sistema así designado es un sistema
que, simultáneamente:
 Implementa las funciones de seguridad requeridas necesarias para
lograr o mantener un estado seguro del EUC; y
 Está previsto para alcanzar, por sí mismo o con otros sistemas E/E/PE y
otras medidas de reducción del riesgo, la integridad de seguridad
necesaria para las funciones de seguridad requeridas.” (IEC 61508:2010
3.4.1).

Otras medidas de reducción del riesgo: “Medida para reducir o mitigar el riesgo

que está separada, es distinta y no utiliza los sistemas E/E/PE relacionados con la
seguridad” (IEC 61508:2010 3.4.2).

Capa de protección: “Cualquier mecanismo independiente que reduzca el riesgo

mediante el control, la prevención o la mitigación” (IEC 61511:2016 3.2.57).
De manera simplificada podría decir que la Seguridad Funcional es la que
depende de la(s) Función(es) de Seguridad asociada a un peligro
particular.
El término manejado por las otras referencias citadas, diferentes a las
normas, solo se refieren a la Seguridad Funcional que depende de
los sistemas E/E/PE relacionados a la seguridad o el SIS.

En este caso particular, se podría decir entonces que la Seguridad

Funcional es la que depende de que un sistema (hardware y software)
especificado para brindar seguridad, funcione (responda adecuadamente a
los estímulos de entrada y genere las salidas requeridas). El sistema debe

26
 responder de manera satisfactoria tanto a condiciones externas (demandas
del proceso, condiciones ambientales) como a fallos internos (fallas
sistemáticas, aleatorias o de causa común) para asegurar que no resulten
en daños a personas, el ambiente, las instalaciones y/o la producción.
Y esto nos lleva al concepto de Integridad de Seguridad, pero este lo
trataremos luego…

PONGA A PRUEBAS SUS CONOCIMIENTOS.

Preguntas de esta entrada:
1-  ¿Mencione al menos 5 sistemas, conocidos como Otras Medidas de Reducción de
Riesgo u Otras Capas de Protección en la industria de los procesos?
2-  ¿Mencione al menos 5 Sistemas, conocidos como sistemas E/E/PE relacionados a
la seguridad o el SIS en la industria de los procesos?

Bloques de Confiabilidad y PFDavg de acuerdo

con la Norma IEC 61508
En la norma IEC 61508 (2010) parte 6, se describen ecuaciones para el cálculo de la
Probabilidad de Falla en Demanda promedio de distintas arquitecturas mediante la
metodología de Bloques de Confiabilidad. En la Figura 1 se muestra el diagrama de
bloques de confiabilidad para la arquitectura 1oo1, la cual consiste en un solo canal,
donde cualquier falla peligrosa conduce a la pérdida de la función de seguridad
cuando exista una demanda.
 

Figura 1. Diagrama
de Bloques, Arquitectura 1oo1

27
  

Debido a que la tasa de falla peligrosa (λ D) viene dada por la suma de la tasa de falla
peligrosa detectada por diagnóstico (λDD) y la tasa de falla peligrosa no detectada (λ DU),
el diagrama de bloques de confiabilidad puede ser expresado como el mostrado en la
figura 2.

Figura 2. Diagrama de Bloques de Confiabilidad

PFDavg1oo1. Fuente: IEC 61508 (2010)

Así, la tasa de falla peligrosa (λD) de un canal puede ser dividida en dos bloques en un
arreglo en serie representado por las tasas de fallas λ DD y λDU, Esto permite calcular  la
Probabilidad de Falla en Demanda promedio del bloque sumando la probabilidad de
falla equivalente de cada componente. Por lo que de acuerdo a la norma IEC 61508 –
6, la Probabilidad de Falla en Demanda promedio de esta arquitectura es:

PFDavg  = (λDU+λDD)tce
tce:   Tiempo medio de inactividad.
λDU: Tasa de falla peligrosa no detectada.
λDD: Tasa de falla peligrosa detectada.
 
La porción de tiempo de inactividad de la función (t ce) puede entenderse de la
ecuación de la siguiente manera (Ver figura 3): 1. El sistema está inactivo debido a
una falla peligrosa no detectada (λ DU), hasta que esta condición sea revelada mediante
la prueba de periodica (Ti) y adicionalmente debe hacerse la reparación respectiva
luego de la detección (MRT) ó 2. El sistema esté en reparación (MTTR) debido a que
se encontró un problema en las pruebas de diagnósticos, asociado ésto a la tasa de
falla peligrosa detectada (λDD), Por lo que se calcula mediante la siguiente ecuación:

tce=(λDU/λD)*(Ti/2+MRT)+(λDD/λD)*MTTR

28
 Figura 3. Interpretación del Tiempo de Inactividad del Sistema

Referencias

 Norma IEC 61508 (2010). Functional safety of

Electrical/electronic/programmable electronic
safety-related systems

 Norma IEC 61511 (2016). Functional safety – Safety instrumented

systems for the process industry sector.
 https://es.wikipedia.org/wiki/Seguridad_funcional
 Smith, D (2011). Safety Critical Systems Handbook
 http://www.ul.com/es/
 https://www.tuvasi.com/
 www.ul.com/es/
 Norma IEC 1078 (1991). Analysis techniques for dependability – Realibility
Block Diagram method
 Norma IEC 61508 – 6 (2010). Guidelines on the application of parts 2 and 3

29
30