Diseño

Análisis del Método RBD para la Determinación de la PFD de los Elementos de una SIF

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, 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 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 (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

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.

Nivel de Integridad de Seguridad (SIL)

Probabilidad de Falla en
Demanda Promedio (PFDavg)

Reducción de Riesgo
Requerida (FRR)

4

≥10−5 a <10−4

>10.000 a ≤100.000

3

≥10−4 a <10−3

>1.000 a ≤10.000

2

≥10−3 a <10−2

>100 a ≤1.000

1

≥10−2 a <10−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 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 esquemade 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.

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.

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 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 .

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 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.

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.

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)

;       (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

[1]

Guo H., Yang X. “A simple reliability block diagram
method for Safety integrity verification”. Reliability Engineering and
Systems Safety 92 (2007). Elsevier.

[2]

Creus A., “Fiabilidad y Seguridad”, Marcombo Ediciones
técnicas, 2da Edición 2005

[3]

Fernandez I. et al. “Sistemas Instrumentados de
Seguridad y análisis SIL”, ISA Sección España Diaz de Santos. 2012

[4]

Magnetrol. “Understanding Safety Integrity level”
Special application Series.

[5]

IEC 61508. “Functional safety of electrical/electronic/programable
electronic safety-related systems. Part 6. Guideline on the Applications of
IEC-61508-2 and IEC-61508-3.

[6]

IEC 61511. “Functional safety” safety instrumented systems
for process industry sector, Part 1, part 2 and Part 3.

 

Raúl Roque

Santa Cruz – Bolivia

FSEng TÜV SÜD TP18051528

Romel Rodriguez

Functional Safety Expert TÜV SÜD TP18010990 | ISA84/IEC 61511 Expert | FSEng TÜV Rheinland 575/07 | PHA Leader

 

Análisis del Método RBD para la Determinación de la PFD de los Elementos de una SIF Leer más »

Desde El Mundo Del Pensamiento Posterior, A Las Buenas Prácticas De Programación

Desde que existen los sistemas programables en aplicaciones de seguridad y de control, tenemos la tentación de pensar que cualquier problema es solucionable con programación y que el software da para todo y en cualquier instancia de la vida útil del sistema. Alguna vez escuche la frase asociada a que el software es el mundo del pensamiento posterior y la misma estaba atada a esa creencia de que podemos resolverlo todo en el momento que se presente el problema, no previendo el problema. Eso en seguridad funcional se puede pagar muy caro.
Cuando se crea o codifica una aplicación, existe un número casi infinito de soluciones programables que satisfacen los mismos requisitos funcionales. Sin embargo, no todas estas soluciones o programas comparten los mismos niveles de calidad. Es decir, no todos son igualmente eficientes en el consumo de recursos (por ejemplo: memoria del procesador), legibles, fáciles de probar y fáciles de mantener.
En seguridad funcional, no basta con crear el Programa de Aplicación que funcione correctamente sino además, este debe ser robusto, eficiente, documentado, fácil de mantener, de actualizar y de probar. En general, muchas personas están capacitadas para codificar aplicaciones pero un número bastante reducido de ellas están capacitadas para hacerlo conforme a los parámetros de calidad (integridad) que se requiere, según la norma IEC 61511, para el Programa de Aplicación de los Sistemas Instrumentados de Seguridad.
Esta norma define los requisitos para la elaboración de la solución lógica específica para la aplicación del usuario que contiene, en general, las secuencias lógicas, permisivos, límites y expresiones que controlan las entradas, las salidas, los cálculos y las decisiones para cumplir los requisitos funcionales del SIS (IEC 61511: 2016 – Clausula 3.2.76.1); además, establece un ciclo de vida para su gestión como el que se muestra a continuación.

Ciclo de Vida de Seguridad del programa de aplicación.
La norma IEC 61511 contempla en su apartado 12, que se realice un Programa de Aplicación que pueda ser gestionado, lo que implica que esté bien documentado, sea trazable, que permita su modificación de manera sencilla, sea modular, tome en cuenta las restricciones del hardware, se utilicen adecuadamente las librerías incluidas, entre algunos otros aspectos que se deben considerar. Además, se debe garantizar en todo momento que el diseño y la implementación de las Funciones Instrumentadas de Seguridad (SIF) logren la Seguridad Funcional requerida.
 
Cuando decimos que el Programa de Aplicación debe estar bien documentado, debemos asegurarnos de indicar claramente las SIF soportadas y su Nivel de Integridad de Seguridad (SIL), tiempo de activación, tiempo de retardo, descripción de la función, sintaxis de los tag utilizados, rangos de operación, escenarios y modos de operación, comentar rutinas o pasos claves del programa, no dejar nada a la imaginación o asumir que cualquier programador lo entenderá.
 
No debemos perder de vista aspectos importantes de rendimiento y eficiencia del programa de aplicación, revisar y probar orden de ejecución, permisivos, memoria utilizada, modos de funcionamiento, límites en datos y parámetros, bugs, bypass, identificar los estados peligrosos que puede generar el programa de aplicación y diseñar su solución.
 
Como último punto y no menos importante, se deben crear las facilidades dentro de la estructura del Programa de Aplicación para las rutinas de las facilidades de mantenimiento, autodiagnósticos de dispositivos externos, ensayos periódicos, pruebas de diagnósticos, auto-monitoreo del propio programa.
 
En resumen, y como buenas prácticas, se debe programar teniendo en cuenta:
  • Gastar los recursos como propios. Lograr el mejor uso posible de los recursos.
  • Codificar para niños (a prueba de tontos). Escribir los programas lo más simple y directo posible, buscando optimizar el rendimiento de la aplicación.
  • Documentar pensando en el otro. Todo programa debe ser previamente comentado, explicando brevemente el propósito, funcionamiento y el resultado esperado.
  • Estructurar para que te lea hasta tu abuela. Dentro de las funciones definidas, establecer un espaciado, que resalte la estructura funcional de la aplicación y facilite la lectura al programador al que le corresponda analizar el código.
  • Usar las ventajas disponibles. Gestionar los errores de hardware y la pérdida de datos, incluir autodiagnósticos de los sistemas con quien  interactúa como los sensores de campo y elemento final.
  • Ordenar la casa. Definir el orden de los programas, rutinas, secuencia de tareas, quien va primero y quien después.
  • Guardar tus secretos y mantener tu seguridad. Tomar en cuenta y definir claramente los niveles de acceso y protección del software.
  • Armar una buena caja de herramientas. Seleccionar y aplicar los métodos, técnicas y herramientas necesarias, según la fase del ciclo de vida.
  • Tipificar soluciones confiables. Definir bloques típicos y manual de aplicación para soluciones particulares, utilizando las librerías disponibles señaladas en el manual de seguridad.
  • Controlar las Versiones. Llevar una bitácora de las cambios y mejoras realizadas en cada versión del programa de aplicación y definir un lugar específico donde esté resguardada la más actual.
  • Probar, probar y probar.
“La imaginación exagera, la razón subestima, el sentido común modera.”
Marlene Dietrich (1901-1992) Actriz y cantante alemana.
Luis Durán 
FSEng TÜV SÜD TP18051526
Romel Rodríguez
Functional Safety Expert TÜV SÜD TP18010990 | ISA84/IEC 61511 Expert | FSEng TÜV Rheinland 575/07 | PHA Leader

Desde El Mundo Del Pensamiento Posterior, A Las Buenas Prácticas De Programación Leer más »

¿Certificado o No Certificado? ¿Realmente es eso un dilema?

¿Qué dice la norma IEC 61511 respecto a que un equipamiento, persona u organización esté certificado? Pues nada, realmente nada.
Lo que sí dice, en cada caso, es que:
  • Las organizaciones que desarrollan actividades relacionadas al Sistema Instrumentado de Seguridad deben poseer un Sistema de  Gestión de la Seguridad Funcional.
  • Las personas que hacen tareas relacionadas con los Sistemas Instrumentados de Seguridad, que posiblemente hacen vida laboral en las organizaciones antes mencionadas, deben ser competentes para realizar las tareas de las cuales son responsables.
  • El equipamiento a utilizar en los Sistemas Instrumentados de Seguridad debe ser diseñado, construido y operado conforme a la normativa.
Pero, ¿es una desventaja que la norma no diga que algo debe estar certificado? Para mí, es todo lo contrario.
En primera instancia, quienes desarrollan las normativas hacen lo correcto en no tomar partido respecto a la necesidad de una certificación, dado que eso es un proceso que podría favorecer a un ente certificador en específico. Sólo he visto un reporte técnico de ISA, relacionado a la Seguridad Cibernética, que nombra en forma explícita la necesidad de una acreditación para asegurar las competencias del personal.
Alguien podría pensar entonces que la certificación es simplemente una actividad de lucro y nada más (argumento muy común, por cierto) pero, en realidad, la certificación como proceso de demostración de capacidad respecto a unas especificaciones particulares por parte de un tercero, ofrece enormes beneficios para todos los involucrados. A continuación, nombraré algunos ejemplos.
A nivel organizacional, supone una gran ventaja en la contratación de servicios y en la procura de equipamiento. Una organización que contrata servicios a otra que posee un Sistema de Gestión de Seguridad Funcional certificado, descarga la gran cantidad de trabajo que supone realizar las tareas de verificación, evaluación (assessment) y gestión, que la organización contratada ejecutará como parte de sus procesos internos. Esto hace que la inversión de horas hombre por parte del contratante para obtener un documento/servicio conforme a la normativa sea menor. Por parte de la organización certificada posee un elemento diferenciador en el mercado al ofrecer servicios que estén de conformidad con la norma dándole un mejor posicionamiento.
En el caso de la certificación de competencias del personal, existe una variedad de ofertas en el mercado y todas apuntan a facilitar la forma de demostrar que el personal posee un nivel de competencias específico. La calidad de la certificación dependerá del ente acreditado que la emite y del tipo de programa que representa, los años en el mercado, el nivel de independencia, el cuerpo que le acredita, el modelo utilizado (ISO – 17024), el objeto de la certificación (conocimiento o experiencia), entre otros factores. La certificación de personal le permite al contratante simplificar sus procesos de selección y evaluación, evitando la necesidad de realizar una comprobación de competencias individual, a cada persona, cada vez que se realiza un trabajo relacionado al ciclo de vida de seguridad. Por su parte, las personas certificadas pueden demostrar un conocimiento adquirido o una competencia particular, lo que se traduce en una ventaja en el mercado laboral.
En el equipamiento, es muy importante entender que cuando una organización compra un equipamiento que posee un certificado, lo que está comprado en forma implícita es un dispositivo creado por una organización que posee un Sistema de Gestión de Seguridad Funcional que se ha encargado de diseñar y fabricar ese equipamiento de conformidad con la normativa, liberando al contratante de una cantidad de trabajo gigantesca que supone crear un equipamiento o documentarlo, en función de hacerlo compatible con la normativa.
En el mercado existe también una gran cantidad de equipos certificados, es su responsabilidad verificar que el equipamiento (aun estando certificado) se ajuste a su realidad operacional. El certificado no es un pase libre ni mucho menos. He visto certificados de agencias internacionales que son inverosímiles y otros usados en aplicaciones no compatibles con la realidad operacional del cliente (maquinaria vs procesos). La organización que certifica su
equipamiento tendrá acceso a un mercado específico y poseerá una ventaja sobre sus competidores.
El proceso de certificación representa una cantidad de esfuerzo significativo tanto para el ente que emite la certificación como para quien se somete al proceso de certificación y de allí que sea una actividad de lucro, pero es también sin duda una vía expedita en la que todos los involucrados en la Seguridad Funcional ganan. Todos sin excepción: organizaciones y personas.
Como todo en esta vida, Ud. debe tomar sus previsiones a la hora de escoger una organización, una persona o un equipamiento certificado o no certificado. Realmente no existe un dilema derivado de ese hecho, en esta tarea, nada reemplazará su buen juicio, y eso al final es lo más importante.
Romel Rodríguez
CSF Consultoría en Seguridad Funcional
rodriguezrx@grupocsf.com

¿Certificado o No Certificado? ¿Realmente es eso un dilema? Leer más »

Diseño Básico del SIS: ¿Cómo saber si la tasa de falla que estamos usando es adecuada?

La calidad del modelo que se crea para representar una Función Instrumentada de Seguridad (SIF) es altamente dependiente de la calidad de los datos que usemos para hacer la predicción de su comportamiento; bien sea calculando la Probabilidad de Falla en Demanda Promedio (PFDavg) o la Frecuencia de Fallas por Horas (PFH). Es una preocupación genuina, para quienes tienen la responsabilidad de cuantificar la falla aleatoria de la SIF, la necesidad de buscar el dato que les permita hacer la mejor representación posible.
 
La norma IEC-61511-2016 en su cláusula 11.9.3, describe claramente que: 

Los datos de confiabilidad utilizados para cuantificar la tasa de fallas aleatorias deben ser creíbles, trazables, documentados y justificados y se basarán en la información de campo de dispositivos similares utilizados en entornos operativos similares”.

La intención de incluir esta cláusula en la versión 2016 es hacer énfasis justamente en la calidad del dato que se debe usar.
 
Pero, ¿qué quiere decir con que la tasa de falla sea creíble? La tasa de falla debe tener un valor que corresponda con el tipo de equipamiento y la realidad operacional donde se pretende utilizar. Usar datos que se puedan considerar muy optimistas y que resulten en modelos de SIF con prestaciones muy altas (muy bajas PFDavg /PFH o SIL muy altos) ocasionará una percepción de una reducción de riesgo errónea, exponiéndonos a un accidente potencial. Cada familia de equipamiento tiene unos valores máximos y mínimos que son considerados válidos para un ambiente operativo particular. Recordemos que una tasa de falla no es un valor único sino un valor tomado de una colección de valores (puede ser la media) que representan el comportamiento estadístico del equipo en particular. Bases de datos como OREDA, CCPS, IEEE y EXIDA pueden expresarlos de diversas maneras, una curva normal o valores máximos y mínimos. Así que la próxima vez que vea un dato muy optimista piénselo dos veces y compárelo.
 
¿Qué debemos buscar sobre la procedencia del dato?, ¿Qué quiere decir con que la tasa de falla sea trazable? Cuando una organización publica un valor de tasa de falla, tiene el deber de explicar cómo se obtuvo: Si se estimó basado en datos de campo (¿en qué condiciones operativas y ambientales?) o en base al retorno de partes a fabricantes o en predicciones basadas en técnicas como Análisis de Modos y Efectos de Fallas y Diagnósticos (FMEDA) o inclusive en técnicas combinadas de estimación y predicción (por ejemplo, usando teoremas de Bayes).
 
¿Cómo debe ser la fuente de donde obtenemos el dato? ¿Qué quiere decir con que la tasa de falla sea documentada? La organización que publica un dato no solo debe decir de dónde proviene sino, además, debe indicar cómo es el proceso mediante el cual se obtuvo. Si la tasa de falla proviene de un proceso de recolección de datos en campo, se debe indicar cuál es el esquema utilizado para documentar ese proceso (ISO 14224, IEC 60300 3-2-2004, BS 13460, PERD, OREDA) y si es de una predicción, se debe indicar qué método se utilizó (B10, FMEDA); es fundamental que se de fe que el proceso de generación del dato fue realizado de manera organizada y estructurada y permite documentar la fuente del dato, el proceso de generación y el reporte del mismo.
 
Finalmente, el uso de una tasa de falla particular es decisión de quien hace el modelado de la SIF y es éste quien tiene que justificar la escogencia de un dato en específico. La decisión es suya. Entonces, ¿qué quiere decir con que la tasa de falla sea justificada? La justificación de escogencia debe atender a la mejor representación de su realidad operacional, entorno ambiental, políticas de gestión de integridad mecánica de los sistemas, etc.
 
Como consejo final, tómese su tiempo para verificar si las tasas de falla que va a escoger podrán ser justificadas, si son creíbles, trazables, están bien documentadas y están basadas en datos de campo en condiciones operacionales similares, permitiéndole asegurar que su diseño estará conforme con el SIL objetivo.
 
Hasta una próxima oportunidad,
Autores:
José Luis Mota – SOIVEN
FSEng TÜV SÜD TP18051527
Romel Rodriguez – CSF
Functional Safety Expert TÜV SÜD TP18010990 | ISA84/IEC 61511 Expert | FSEng TÜV Rheinland 575/07 | PHA Leader

Diseño Básico del SIS: ¿Cómo saber si la tasa de falla que estamos usando es adecuada? Leer más »

Tolerancia de Falla por Hardware, Ruta 2H

En el post anterior, se explicaron las restricciones de arquitectura para una SIF, de acuerdo con la Ruta 1H de la norma IEC 61508, basada en la Fracción de Falla Segura (Tasas de Falla Segura y Peligrosas) de los elementos de las SIF y los tipos de dispositivos (Tipo A y Tipo B). Sin embargo, cuando la SIF está operando y sus instrumentos no poseen un certificado del fabricante que indique las tasas de falla y su SFF, es difícil darle crédito por la Ruta 1H, por lo que, en estos casos, se usa la Ruta 2H.
Las características principales de esta ruta son:
        Es usada para los dispositivos bajo el concepto de Prior in Use.
      Está basada en la retroalimentación de los datos de las tasas de falla de los dispositivos de campo que son usados en una aplicaciones similares y entornos similares, y debe ser evaluada de acuerdo con:
 
          La cantidad de datos recopilados.
          El juicio de expertos.
          Y, cuando sea necesario, pruebas específicas.
 
      Se requiere un sistema de recopilación de datos de alta calidad de acuerdo con estándares internacionales, por ejemplo, IEC 60300-3-2 o ISO 14224.
        No toma en cuenta la SFF.
        Tiene una sola tabla para los dispositivos Tipo A y Tipo B. 
 
En la tabla 1, se muestra un resumen del mínimo de HFT requerido, de acuerdo con Ruta 2H de la norma IEC 61508, en su cláusula 7.4.4.3.
 
Tabla 1. Ruta 2H. IEC 61508
SIL
Mínimo HFT Requerido
1 (Cualquier modo)
0
2 (Modo Bajo Demanda)
0
2 (Alta demanda, o modo continuo) *
1
3 (Cualquier modo) *
1
4 (Cualquier modo) *
2
* Sólo para elementos tipo A, si el HFT escogido resulta en una arquitectura que desmejora la seguridad del proceso, se puede:

   Reducir el HFT, justificando y documentando la reducción de la arquitectura y la desmejora de la seguridad argumentada.
     Si el HFT = 0, se debe proporcionar evidencia de que los modos de falla peligrosa pueden ser excluidos.

Tolerancia de Falla por Hardware, Ruta 2H Leer más »

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 (PFDavg: 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 PFDavg 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 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

SFF

Tolerancia de falla de Hardware (Hardware Fault Tolerance)

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):

  • 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 PFDavg 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

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:

 

 

Reducciones de Arquitectura Según IEC 61508 Leer más »

Comencemos por el principio: Fracción de Falla Segura, Redundancia y Restricciones de arquitectura

Si decimos que un Sistema Instrumentado de Seguridad es tan fuerte como el más débil de sus componentes, debemos escoger el hardware que ofrezca las mejores prestaciones posibles.

Una de las características que definen un componente como “bueno”, en el entorno de la Seguridad Funcional, es la Fracción de Falla Segura (SFF: Safe Failure Fractión (IEC 61503-3: 2010 – 3.6.15)); que es definida como la porción de fallas seguras (detectadas o no por diagnósticos) del total de las fallas de un elemento. El término es una indicación de que tan bien ha sido diseñado un elemento (es decir, cuanto diagnóstico ha sido colocado en él). 

Ecuación 1. Fracción de Falla Segura
(SFF)

Realizar una función de seguridad por un elemento puede ser una tarea difícil de alcanzar en términos de desempeño (SIL), por lo que el diseñador muchas veces recurre a la colocación de múltiples elementos, para realizar la misma tarea o función, a fin de incrementar los chances éxito. Esté es básicamente el concepto de Redundancia (IEC 61508-3: 2010 – 3.4.6).

Un subsistema es redundante (desde el punto de vista de seguridad) cuando, al fallar uno de los elementos, tiene al menos un elemento más que le permite seguir funcionando correctamente. La redundancia puede ser Idéntica: si los elementos son idénticos en cada característica, o puede ser Diversa: cuando los elementos son diferentes entre sí físicamente o de filosofía.

 

Para dar una guía sobre el uso adecuado de la redundancia (o la falta de ella) y evitar sobre estimar el valor que se le puede otorgar a las disposiciones de diseño de un solo elemento, que pudieran llegar a ser poco realistas (SFF, Ti, etc.), la normativa ha tomado en cuenta unas Restricciones de Arquitectura, donde se establece cuantas fallas puede tolerar un elemento para mantener un desempeño determinado (SIL). Estas restricciones vienen expresadas en términos de Tolerancia de Fallas por Hardware (HFT: Hardware Fault Tolerance (IEC 61508-2: 2010 – 7.4.4)). Es decir, cuantas fallas se pueden tolerar y aun poder seguir ofreciendo el mismo desempeño, como pueden observar es en realidad una medida de éxito para el SIS.

La Tolerancia de Falla por Hardware de cada elemento o subsistema puede ser determinada por la norma IEC 61508 o la norma IEC 61511.

 HFT según IEC 61508

Si se decide seguir lo lineamientos de IEC 61508, 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 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

SFF

Tolerancia
de falla de Hardware (Hardware Fault Tolerance)

0

1

2

< 60 %

No sepermite

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

 

HFT según IEC 61511

El mínimo HFT de una SIF para un SIL especifico de acuerdo con la norma IEC 61511 debe estar de acuerdo con la Tabla 3.

 Tabla
3. Mínimos requerimientos de HFT de acuerdo con el SIL. IEC 61511
-2016

SIL

Mínimo HFT Requerido

1 (Cualquier modo)

0

2 (Modo Bajo demanda)

0

2 (Modo continuo)

1

3 (Alta demanda, o modo continuo)

1

4 (Cualquier modo)

2

Votación y Redundancia

Se dice que un SIS (o parte del mismo) es NooM, cuando tiene M elementos independientes, conectados de tal forma, que N elementos son necesarios para ejecutar la SIF. Donde,

N Expresa el número de votación

M expresa la redundancia

Desde el punto de vista de Seguridad no todas las arquitecturas NooM son redundantes.  Por ejemplo, para una falla:

  • 1oo2 es redundante (1 es necesario de 2 disponibles)
  • 2oo2 no es redundante (2 son necesarios de 2 disponibles).

Una HFT = x significa que x+1 fallas peligrosas llevarán a la pérdida de la función de Seguridad.

Para NooM se define HFT=M-N, por ejemplo, para una arquitectura 2oo3, HFT=3-2=1, será capaz de tolerar una sola falla.

En forma análoga podría definirse la Tolerancia de Falla Seguras del Hardware como:

HFTs=N-1.

Donde un HFTs = y significa que se requieren y+1 fallas seguras para alterar la disponibilidad del proceso.

De igual manera, el HFTs de una arquitectura 2003 será, HFTs=2-1=1.

En la siguiente entrada del Blog, como el  SIL es una cuestión de tiempo…

 

PONGA A PRUEBA SUS CONOCIMIENTOS.

 Preguntas de esta entrada:

1-     En la tabla indique, el número de votación, el número de redundancia, el HFT y HFTs de las siguientes arquitecturas NooM.  

 

 

Comencemos por el principio: Fracción de Falla Segura, Redundancia y Restricciones de arquitectura Leer más »

Probabilidad de Falla en Demanda Arquitectura 1oo2

Las ecuaciones para el cálculo de la Probabilidad de Falla en Demanda promedio (PFDAVG) para diferentes arquitecturas están descritas en la norma IEC 61508: 2010 parte 6, mediante la metodología de Bloques de Confiabilidad.

En la Figura 1 se muestra el diagrama de bloques de confiabilidad para una arquitectura 1oo2, la cual consta de dos canales, en donde es necesario que ambos elementos estén fallados al mismo tiempo para que ocurra la pérdida de la función de seguridad en caso de demanda.

Figura 1. Arquitectura 1oo2.

La ecuación para determinar la PDFAVG para una arquitectura 1oo2, de acuerdo a lo indicado en la norma 61508: 2010, es la siguiente:

donde,

  • βD. Factor de Falla de Causa Común
  • MTTR. Tiempo Medio de Reparación
  • MRT. Tiempo Medio de Restauración
  • λDD. Tasa de Falla Peligrosa Detectada
  •  λDU, Tasa de Falla Peligrosa no Detectada
  • tCE. Tiempo medio de inactividad equivalente de un canal.
  • tGE. Tiempo medio de inactividad equivalente de todos los canales.

(http://csf-andreinacabeza.blogspot.com/2016/07/bloques-de-confiabilidad-y-pfdavg-de.html)

Para establecer como funciona el modelado de esta arquitectura usando esta ecuación, es necesario entender cuando una arquitectura de un subsistema no está disponible para realizar su función. La arquitectura 1oo2, no estará disponible debido a alguna falla de causa común que saque de servicio ambos elementos, o que ambos elementos (A y B) no estén disponibles por alguna razón, por ejemplo, de que el elemento A esté siendo reparado mientras el elemento B esté fallado por alguna falla oculta.

Dividiendo la ecuación en 3 partes para su análisis, la arquitectura no estará disponible si:

1.                 Una falla común es detectada y está siendo reparada durante un tiempo MTTR (Tiempo Medio para Reparar), correspondiente a 

2.                 Mientras se realiza la Prueba de Inspección (Ti) se revela una falla oculta, y es necesario reparar durante un tiempo determinado (MRT – Tiempo Medio para Reparar), correspondiente a

3.              Ó por alguna combinación de que un elemento falle cuando el otro no esté disponible, que está representado por ende la ecuación por:

En este último punto están representadas las fallas no comunes (individuales), y asumiendo que el modo común de falla (β) es muy bajo (aproximadamente 0), las tasas de fallas se pueden escribir de la siguiente manera (a modo ilustrativo):

Lo que de acuerdo con la Figura 1, para una arquitectura 1oo2, significa que:

      • Ambos elementos fallan de manera peligrosa detectada en forma simultánea (lDD2).
      • Un elemento falla de manera peligrosa detectada y otro de manera no detectada en forma simultánea (2lDDlDU).
      • Ambos elementos fallan de manera peligrosa detectada en forma simultánea (lDU2).

 

Probabilidad de Falla en Demanda Arquitectura 1oo2 Leer más »

Bloques de Confiabilidad y PFDavg de acuerdo a 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
 
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
PFD
avg1oo1. Fuente: IEC 61508 (2010)
Así, la tasa de falla peligrosa (λDde 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 d
e 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 (tce) 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
Figura 3. Interpretación del Tiempo de Inactividad del Sistema
Referencias
 
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

Bloques de Confiabilidad y PFDavg de acuerdo a la Norma IEC 61508 Leer más »