SIF

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

Diseño / /

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 »

Todo cambia, incluido su SIS: El porqué de la necesidad de gestionar el cambio

Gestión de la Seguridad Funcional / /
En seguridad funcional, como parte del programa de integridad mecánica, se deben establecer los lineamientos, responsabilidades y actividades que permitan evaluar, registrar, comunicar e implementar todos los cambios temporales o permanentes asociados a los Sistemas Instrumentados de Seguridad (SIS). 
 
Dicho esto, una vez implementado el SIS y estando ya en operación, pueden presentarse infinidad de factores por los cuales se requiera una modificación del mismo. Los motivos pueden ir desde un diseño inadecuado (que comprometa la confiabilidad del SIS), la ampliación de un sistema que altere las condiciones iniciales hasta la migración a nuevas tecnologías para incrementar la producción, entre otros.
 
La pregunta es: ¿Cómo podemos asegurarnos de que cualquier modificación a un SIS, sea debidamente planificada, revisada y aprobada previa a la ejecución y que, aun así, se mantenga la integridad de la seguridad?
 
La respuesta es: Gestionando los cambios.
 
Debemos asegurarnos de gestionar todas las modificaciones, provenientes de solicitudes como, por ejemplo:
 
  • Incorporación de nuevos equipos o de nuevas SIF al SIS.
  • Cambios de funcionamiento de la SIF.
  • Eliminación o desmantelamiento de una SIF.
  • Modificaciones para corregir fallos sistemáticos.
  • Modificaciones para mejorar la confiabilidad de los procesos.
  • Actualizaciones o cambios de software embebido o de aplicación.
  • Modificaciones provenientes de cambios en la tasa de demanda del SIS.
  • Modificaciones a procedimientos operacionales.
  • Cambios de marca o modelo de los equipos del SIS.
  • Cambios en los requisitos de integridad para la SIF.
  • Modificaciones para corregir errores de software o firmware.

Y cualquier otro que impacte la seguridad de la instalación como se menciona en párrafos anteriores.
 
Haciendo referencia a los requisitos de la norma IEC61511 (cláusula 16), para llevar a cabo una modificación o cambio debe existir un procedimiento que indique como iniciar, planificar, documentar, revisar y aprobar un cambio a un SIS y considerar previamente:
  • Procedimientos que incluyan un método para identificar el trabajo a realizar y los peligros que pudieran presentarse.
  • Justificación o necesidad del cambio propuesto.
  • El impacto sobre la seguridad y salud de las personas e instalaciones.
  • El posible impacto en otras funciones de seguridad.
  • El tiempo durante el cual permanecerá el cambio (en caso de que sea temporal).
  • El personal responsable de autorizar el cambio (no debe comenzar la modificación sin la debida autorización).
  • El personal que debe ser notificado o capacitado para dicho cambio.
  • El impacto en los procedimientos operacionales existentes.
  • Disponibilidad de espacio de memoria y procesamiento en el sistema.
  • Efectos del tiempo de respuesta del SIS.
  • El impacto en la confiabilidad del sistema.
  • Control de la documentación de todas las modificaciones realizadas al SIS.

La revisión de la propuesta de cambio debe ser realizada por personal competente. Así mismo, el personal que será afectado por el cambio debe ser debidamente informado y capacitado antes de su implementación.
 
Es necesario revisar qué fase del Ciclo de Vida del SIS se ve afectada con el cambio y verificar que los procedimientos y la documentación afectada sea actualizada, preservando un registro de las versiones anteriores. Finalmente, antes de poner en marcha las instalaciones, se debe verificar y validar cada SIF afectada.
 
Como vemos, al disponer de un sistema de gestión para el manejo de los cambios en el SIS es que podemos garantizar:
  • Que se realice un análisis completo y apropiado antes de la implementación del cambio.
  • Que no se afecta la reducción de riesgo proporcionada por las SIF.
  • Que se obtiene la aprobación de las partes afectadas.
  • Que la documentación está completa y es consistente con la aplicación en campo.
  • Que el riesgo de la instalación no se ve afectado negativamente.

En conclusión, todo se trata de la necesidad de proteger y salvaguardar adecuadamente la integridad de la seguridad de nuestros Sistemas Instrumentados siguiendo procedimientos para un control documental apropiado, es decir, gestionar el cambio.
 
Recuerde:
“Lo único constante es el cambio”.
Heráclito (filósofo griego).
 
Ninoska La Concha
FSEng TÜV SÜD TP18051525
Romel Rodriguez
Functional Safety Expert TÜV SÜD TP18010990 | ISA84/IEC 61511 Expert | FSEng TÜV Rheinland 575/07 | PHA Leader

Todo cambia, incluido su SIS: El porqué de la necesidad de gestionar el cambio Leer más »

Equipamiento del SIS ¿Qué debo considerar?

SRS / /

Con el paso de los años, los profesionales y técnicos que trabajan en la industria de procesos se están haciendo más conscientes de la seguridad, enfocándose específicamente en ramas como la Seguridad Funcional.

Es relevante recordar el estudio que realizó la HSE (Health and Safety Executive) del Reino Unido (UK), cuyos resultados arrojaron que el origen de las fallas y accidentes se debían en un 44% a malas especificaciones y un 15% a errores de diseño e implementación. De ahí la importancia de poder detectar las posibles fallas y prácticas erróneas que se cometieron durante las diferentes fases iniciales del Ciclo de Vida de Seguridad, especialmente en la fase de Diseño e Ingeniería del Sistema Instrumentado de Seguridad (SIS).

Normalmente, las personas que dicen “trabajar de forma segura”, siguiendo los requerimientos de la normativa IEC-61511:2016, no van más allá de la fase de Especificaciones de los Requerimientos de Seguridad (SRS) o saltan directamente de a la fase de Validación del SIS, asumiendo que la ingeniería del proyecto cubre lo requerido para el SIS.

En este punto, se crea un quiebre en el Ciclo de Vida de Seguridad Funcional, dejando sin validez todo el trabajo previo y el que se debe realizar. A continuación, les comento las razones.

Generalmente, cuando definimos las características técnicas del equipamiento de seguridad que va a formar parte del SIS, aún se suelen especificar los mismos equipos e instrumentos que son utilizados para el Sistema Básico de Control de Procesos (BPCS).

Cuando se elaboran las hojas de datos de los equipos, a pesar de que se utilice el mismo formato de hojas de datos recomendado por la ISA S20 – Instrument Specification Forms, se deben establecer diferencias evidentes al tratarse de una aplicación de seguridad.

Pudiéramos preguntarnos: ¿Un dispositivo utilizado para el BPCS debería ser el mismo para las aplicaciones del SIS?

La respuesta es No. Si colocamos como ejemplo una válvula, los requerimientos de actuación son totalmente diferentes. En el caso de ser utilizada en aplicaciones de seguridad, idealmente tienen que pasar mucho tiempo sin actuar, pero en el momento que se ejecute la demanda no debe quedar en la posición donde ha permanecido durante mucho tiempo, sino que debe actuar para mantener el sistema en un estado seguro. En cambio, para el caso de las aplicaciones de control, la actuación de la válvula tendría un uso continuo con el fin de mantener los parámetros de control dentro de los rangos establecidos.

Ahora bien, ¿Qué se está dejando de especificar cuando hablamos de sistemas de seguridad? ¿Qué es lo importante a considerar?

Conocemos que en un SIS, los instrumentos o equipos que lo conforman juegan un papel fundamental en el campo de la seguridad funcional; por eso, al realizar una selección adecuada de cada uno de los elementos que la componen se está garantizando en buena parte la integridad del sistema.

En la etapa previa de Diseño e Ingeniería del SIS, nos encontramos con la Especificación de los Requerimientos de Seguridad (SRS). Este es un documento base y es la principal referencia, no solo para esta etapa sino para las demás fases del Ciclo de Vida de Seguridad; tal como es especificado en la normativa IEC 61511-1: 2016, este documento recopila información que nos será de utilidad a lo largo de la vida útil del sistema.

Las SRS nos ofrecen una amplia información acerca de los requerimientos funcionales, modos de operación, condiciones ambientales a las cuales se encontrará expuesto el instrumento o equipo y los requerimientos de integridad (en términos del desempeño requerido). También nos puede indicar los requerimientos especiales que se deben cumplir para cada una de las Funciones Instrumentadas de Seguridad (SIF) que conforman el SIS.

Cada una de las SIF descritas en las SRS están conformadas por subsistemas que pueden ser elementos sensores, controladores y/o elementos finales. Cada tipo de subsistema debe tener una Hoja de Especificaciones o Data Sheet que contenga toda la información necesaria para que este sea seleccionado, integrado y aceptado como parte de un SIS.

Este diseño debe estar en concordancia con lo especificado en las SRS y debe ser realizado por personal con las competencias adecuadas y conocimientos sólidos en el área de la seguridad funcional, empleando como guías las normativas IEC 61508-2: 2010 e IEC 61508-3: 2010.

Las Hojas de Especificaciones o Data Sheet de cada elemento debe responder las siguientes interrogantes: ¿La instrumentación tiene las características adecuadas para el entorno operativo donde se desea instalar? ¿Los materiales de construcción de los instrumentos son los adecuados según la aplicación donde se va a instalar? ¿Posee la capacidad sistemática necesaria? ¿Cuenta con las protecciones operativas adecuadas?, ¿El dispositivo es lo suficientemente confiable para alcanzar el PFDavg requerido? ¿El dispositivo cumple con los requisitos de las restricciones de arquitectura? ¿El dispositivo posee una baja tasa de fallas?; lo anterior son solo algunas de las interrogantes que se pueden plantear.

Además, el disponer de una Hoja de Especificaciones o Data Sheet de Seguridad (y que la misma se encuentre actualizada) va más allá de la compra del equipo adecuado. Este documento es referencia a la hora sustituir o reemplazar un equipo durante la Operación y Mantenimiento, garantizando que se haga de forma correcta y ayudando a mantener la seguridad a lo largo de la vida útil de la planta.

Para ello, todo fabricante debería suministrar el Manual de Seguridad (Safety Manual, en inglés), una herramienta básica y de la cual se va a obtener información sobre los requerimientos de operación y mantenimiento de los instrumentos, restricciones de operación, configuraciones de seguridad permitida, limites ambientales permitidos, entre otros.

Ahora llegó el momento de preguntarnos: ¿Hasta qué punto hemos considerado todos estos aspectos al momento de seleccionar los dispositivos para el SIS?

Les invito a que, de ahora en adelante, tengan en cuenta y consideren esta información. La Seguridad Funcional es de suma importancia y cada uno de nosotros aportamos un granito de arena para el resguardo de nuestras instalaciones.

 

Rigleth S. Gragel V.

Ingeniero de Seguridad Funcional

FSCP TÜV SÜD TP18051520

 Romel Rodriguez

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

 

Equipamiento del SIS ¿Qué debo considerar? Leer más »

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

Diseño / /
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 »

Relación entre Interlock, Función de Seguridad, SIF y Permisivos en Seguridad Funcional

SRS / /
En la industria de procesos los Interlocks, Funciones de Seguridad, Funciones Instrumentadas de Seguridad (SIF) y Permisivos son utilizados en algunos de los controles empleados para evitar eventos peligrosos que representan un riesgo para la seguridad; sin embargo, es común que las personas tiendan a confundir estos términos como sinónimos. Este artículo está destinado a aclarar, tanto su significado en el marco de la seguridad funcional como la relación entre los mismos.
Comencemos mostrando algunas de las definiciones asociadas al término Interlock:
  1. Función que detecta una condición fuera de límites, anormal o una secuencia incorrecta y detiene una acción adicional o inicia una acción correctiva (Guidelines for Engineering Design for Process Safety [modified from «interlock system»]).
  2. Función que inicia una o varias acciones predefinidas en respuesta a una condición específica (CCPS-Guidelines for Safe and Reliable Instrumented ProtectiveSystem).

Cuando llevamos estas definiciones a la industria de procesos, nos referimos a un Interlock para describir una función que, al detectar una o varias condiciones anormales (desviación del proceso o de control), ejecuta una o varias acciones para evitar que un evento ponga en peligro a un equipo, sistema o proceso (según sean definidos).
En seguridad funcional, la normativa ANSI/ISA-84.01-1996 sólo utilizaba como referencia el término Interlock para facilitar la comprensión de los nuevos términos introducidos en la misma, por ejemplo:
  • Cláusula 3.1.53 – Otros términos utilizados para el Sistemas Instrumentados de Seguridad (SIS) incluyen Sistema de Parada de Emergencia (ESD, ESS), Sistema de Parada de Seguridad (SSD) y Sistema de Interlock de Seguridad.
  • Cláusula 7.2.3 – El SIS puede contener uno o más Interlocks o funciones de seguridad.
 
    Posteriormente, este término fue rechazado por el Panel de Normas de la ISA 84, siendo remplazado en las normativas actuales (ISA 61511 /IEC61511 /IEC 61508) por “Función de Seguridad”, definiéndolo como:
  1. Función que debe ser implementada por una o más capas de protección, cuyo objetivo es lograr o mantener un estado seguro para el proceso, con respecto a un evento peligroso específico” (61511-2016, 3.2.65).
  2. “Función que debe ser implementada por un sistema E/E/PE relacionado con la seguridad u otras medidas de reducción de riesgos, cuyo objetivo es lograr o mantener un estado seguro para el equipo bajo control (EUC), con respecto a un evento peligroso específico” (IEC 61508-2010, 3.5.1).
Sin embargo, se debe aclarar que a pesar que el término Interlock fue remplazado en la normativa por “Función de Seguridad”, no necesariamente significan lo mismo. Un Interlock sólo puede estar representado por funciones activas (sistema mecánico, de control o instrumentado) y puede ser definido para proteger un sistema, equipo o proceso. En cambio, una Función de Seguridad puede ser representada por diferentes capas de protección, ya sean funciones activas (una válvula de alivio o una función automatizada) o elementos pasivos (dique de contención o aislamiento térmico), en función de proteger un escenario peligroso especifico.
En caso de que una Función de Seguridad sea asignada al Sistema Instrumentado de Seguridad (SIS) durante el Análisis de Peligros y Riesgos (PHA), la función se convierte en una Función Instrumentada de Seguridad (SIF). En este momento, el sector de la industria de procesos define el término SIF como:

  1. Función de seguridad con un nivel de integridad de seguridad especificado que es necesario para lograr la seguridad funcional (ANSI / ISA-84.00.01-2004-1, cláusula 3.2.71). 
  2. Función de seguridad a ser implementada por un Sistema Instrumentado de Seguridad (SIS) (IEC 61511-1: 2016 – 3.2.66).
Para verlo de manera clara, se puede describir una SIF como una función relacionada con la seguridad que tiene por objeto prevenir o mitigar un peligro de proceso específico, mediante el uso de instrumentos y controles como son sensor(es), solucionador(es) lógico(s) y elemento(s) final(es). Cada función asociada a la seguridad y definida como una SIF debe cumplir con las siguientes características:
  • Debe ser diseñada para proteger de un escenario peligroso específico.
  • Debe actuar en un tiempo específico, dentro del tiempo de seguridad del proceso.
  • Deben asegurar que se lleve al proceso a su estado seguro, por lo que a menudo actúan de forma automática.
  • Deber pertenecer al Sistema Instrumentado de Seguridad.
  • Cada SIF debe tener asignado un Nivel de Integridad de Seguridad (SIL). Este es una característica única de la SIF, es decir, solo ella posee SIL, no el instrumento, no el proceso, no la planta, no el controlador. Solo la SIF posee un SIL determinado.
Como vemos, una Función de Seguridad que pertenece al SIS es representada por una SIF, y una SIF puede ser representada por un Interlock, siempre y cuando cumpla con todas las características de una SIF. A su vez, un Interlock puede ser representado por una o más SIF, o por una Función de Seguridad que sea automatizada.  
Adicionalmente, otro término que es comúnmente usado en la industria es el de Permisivos, algunas de sus definiciones son:
  1. Concesión de autorización para hacer algo (Collins Concise English Dictionary).
  2. Condición dentro de una secuencia lógica que debe cumplirse antes de que se permita que la secuencia pase a la siguiente fase (ANSI / ISA-84.01-1996, Cláusula 3.1.36).
El Permisivo es normalmente referido a una parte de la lógica que requiere que se cumpla una condición especifica de permitir una acción de proceso adicional y se usan a menudo para reducir la posibilidad de que un error humano cause un evento peligroso. Por ejemplo: cierre de una válvula específica antes de abrir otra o manejo del nivel de operación normal de un tanque, antes de la activación del sistema de bombeo.
 
Para cerrar, describiremos un ejemplo que nos muestre de manera simple la relación entre estos cuatro términos.
ssss
Figura 1. Sistemas de Bombeo de Crudo
provenientes del tanque de almacenamiento TK-51 a través de las bombas
centrifugas P-51A/B.
 
Comencemos identificando el Interlock encargado de proteger el sistema de bombeo, el cual puede estar relacionado a una serie de desviaciones y acciones, por ejemplo:

Desviaciones:

  • Bajo nivel en el tanque TK-51, a través del transmisor de nivel LZT-52.
  • Baja presión de succión de las bombas P-51A/B, a través del transmisor de presión PZT-52.
  • Alta presión de descarga de las bombas P-51A/B, a través del transmisor de presión PZT-53.
Acciones:
  • Apagado de las bombas P-51A/B.
  • Cierre de la válvula XV-52.
  • Alarma de activación del Interlock I en el BPCS.
En este caso, como mencionamos anteriormente, el interlock fue definido para la seguridad del sistema, es decir, la protección del activo (Bomba P-51A/B); sin embargo, se puede dar el caso de que sea definido para la protección de un escenario peligroso específico, al igual que se realiza con las funciones de seguridad.
 
Para definir las funciones de seguridad, el primer paso es identificar los escenarios de riesgo, y para cada escenario peligroso se identifican las funciones de seguridad.
 
Por ejemplo, para el escenario “Posible daño mecánico a las bombas de crudo P-51A/B producido por un evento de muy bajo nivel en el tanque TK-51” se hace necesario proteger las bombas P-51A/B; por lo que, se puede definir una función de seguridad de “Protección por muy bajo nivel bombas de crudo P-51A/B”. La misma puede ser implementada por una SIF que tenga el objetivo de detener la operación de la bomba P-51A o P-51B al detectarse muy bajo nivel en el tanque TK-01, a través del LZT-52, en un valor de tiempo determinado y que tenga asociado un SIL para cumplir con el factor de reducción de riesgo requerido.
 
Adicionalmente, el permisivo en este sistema puede ser representado por una función lógica que evite el arranque de las bombas cuando el interruptor de posición de cierre (ZZSL-52) de la válvula XV-52 se encuentre activo.
Cuando trabajamos en seguridad funcional, es importante conocer la diferencia entre estos términos así evitaremos errores que comprometerían el desarrollo del Ciclo de Vida de Seguridad del SIS; por ejemplo, una SIF definida incorrectamente implicaría una Especificaciones de los Requerimientos de Seguridad (SRS) débil, y este error se propagaría a toda la fase de Diseño e Ingeniería del SIS.
 
Responda las preguntas de comprobación aquí:
 

Relación entre Interlock, Función de Seguridad, SIF y Permisivos en Seguridad Funcional Leer más »

Las Especificaciones de los Requerimientos de Seguridad (SRS) y el Ciclo de Vida de Seguridad (CVS) del SIS

SRS / /

Figura 1. Ciclo de Vida de Seguridad
del SIS (IEC-61511-1:2016)

Como expliqué en la entrada anterior, la SRS es un documento que va más allá de garantizar el correcto funcionamiento de los equipos e instrumentos que conforman el SIS. Más que una especificación, lo describo como una Hoja de Datos de Seguridad de la SIF, debido a que contiene información detallada que aporta al diseño, construcción, instalación, operación y mantenimiento de cada SIF, y como influye en todas las fases restantes del CVS, deben ser actualizadas durante toda la vida útil del SIS (o el Ciclo de Vida de Seguridad).

 

Figura 2. Relación de las SRS, con las demás fases del CVS.

Las primeras fases del Ciclo de Vida de Seguridad del SIS son el punto de partida de las SRS. Durante la “Asignación de las Funciones de Seguridad a las Capas de Protección” se identifican todas la Funciones Instrumentadas de Seguridad (SIF) requeridas para los diferentes escenarios peligrosos, determinando su Nivel de Integridad de Seguridad (SIL) y el modo de operación (bajo demanda, alta demanda o modo continuo). Adicionalmente, esta fase aporta información necesaria para el desarrollo de las SRS, como la descripción de los escenarios peligrosos (eventos iniciadores, probabilidad de ocurrencia y consecuencias), estado seguro del proceso, peligros específicos que serán
evitados o suficientemente mitigados, entre otros.

Una vez desarrolladas, las SRS son la base para el Diseño e Ingeniería del SIS. Como bien sabemos, en todos los proyectos de ingeniería tradicional (ya sea básica, conceptual o detallada) se realizan especificaciones de todos los equipos, instrumentos y sistemas (SIS, BPCS, BMS, F&G); por lo tanto, surge la duda ¿Por qué necesito realizar una SRS?

Las especificaciones tradicionales normalmente se desarrollan soportadas en una receta prescriptiva de normativas y/o mejoras prácticas que se basan en identificar el tipo de instrumento o equipo, requisitos de construcción, requisitos generales de instalación (del equipo o instrumento en particular), entre otros; y las especificaciones del SIS normalmente son manejadas como una especificación general del controlador de seguridad. En muchos casos, se emplean filosofías de control que podrían describir cada uno de las funciones que debe realizar el SIS, a veces expresadas como “interlocks”; sin embargo, quedan muchos puntos sin contemplar y de ahí surgen las siguientes dudas ¿Qué peligros estamos evitando al realizar esa función o “interlock”?, ¿Realmente podemos garantizar la seguridad del proceso con las especificaciones “generales” del SIS? y para ser más exactos ¿Realmente podemos garantizar que las SIF son diseñadas en función de alcanzar el SIL requerido?

Al trabajar en seguridad funcional se requiere más que una serie de elementos que se desempeñen de manera adecuada, recordemos que estamos hablando de SIF que deben alcanzar y mantener una integridad determinada.

Si nos enfocamos en el diseño, las SRS aportan información detalla (tanto del hardware como del programa de aplicación), para que cada SIS y sus SIF puedan actuar de la manera correcta, con la configuración correcta, en el tiempo correcto, con el desempeño adecuado y con la integridad necesaria para que pueda alcanzar el SIL requerido. Además, establecen las bases para la verificación del SIL, como son el SIL requerido, arquitectura de votación de los subsistemas (elemento sensor, controlador, elemento final), intervalos de ensayos periódicos (Ti), tiempo de pruebas parciales, tiempo de uso de bypass, tiempo medio de reparación (MRT), entre otros.

Durante la Instalación y Recepción y Validación del SIS, la IEC 61511 establece que “se debe asegurar que las SIF se construyan, instalen y funcionen en concordancia con lo establecido en las SRS”. Para esto se realiza la Validación de Seguridad del SIS, la cual demuestra que la funcionalidad del SIS está conforme a lo establecido en las SRS, antes del arranque de la planta. En la validación se verifica contra las SRS: si se instaló el equipo correcto, si la SIF actúa de modo correcto, si se instaló y configuró la parada manual de manera adecuada, si se configuró el disparo de cada SIF de manera correcta (energizar o des-energizar para disparar), si el SIS actúa de la manera deseada ante una falla revelada, si se configuró el programa de aplicación de manera correcta, si se instalaron las fuentes de energía auxiliares adicionales, si se configuraron los bypass de manera correcta, etc.

Para la fase de Operación y Mantenimiento del SIS, las SRS establecen para cada SIF el intervalo de tiempo en que se deben realizar los ensayos periódicos, el tiempo para realizar las pruebas parciales de cada uno de los componentes, los requisitos para realizar pruebas a las SIF, los requisitos para el uso de bypass, los tiempos de reparación, los requisitos para el uso de la parada manual, acciones que deben realizar los operadores ante una falla del sistema, requisitos para el mantenimiento, requisitos para el arranque y re-arranque del SIS, etc.; los cuales son utilizados como referencia para que se mantenga de forma adecuada el SIL de cada SIF a lo largo de su vida útil y el SIS se opere y mantenga de manera que se no se degrade su integridad de seguridad.

Como vemos, la fase de Especificación de los Requerimientos de Seguridad (SRS) da como resultado la información de referencia más importante y primordial para las fases restantes del Ciclo de Vida de Seguridad (CVS). Ahora, una vez conocido el propósito de las SRS dentro del CVS, qué piensa Ud. sobre la pregunta inicial ¿Es necesario realizar unas SRS?

 Responda las preguntas de comprobación aquí:

Las Especificaciones de los Requerimientos de Seguridad (SRS) y el Ciclo de Vida de Seguridad (CVS) del SIS Leer más »

¿Qué son las SRS?

SRS / /

Las Especificaciones de los Requerimientos de Seguridad o SRS por sus siglas en inglés (Safety Requirement Specification), son definidas en la norma IEC-61511-1:2016 “Functional Safety: Safety Instrumented Systems for the Process Sector” como “Especificación que contiene los requerimientos funcionales para cada Función Instrumentada de Seguridad (SIF) y su Nivel de Integridad de Seguridad (SIL) asociado”.

 

 

La SRS es un documento único o una serie de documentos que establecen los requerimientos funcionales y de integridad del Sistemas Instrumentado de Seguridad (SIS) y sus Funciones Instrumentadas de Seguridad (SIF) asociadas, teniendo en cuenta todos los aspectos técnicos y de gestión que permitan el diseño, la construcción, la instalación, la operación, el mantenimiento y la reparación de dichas SIF.

Cuando desarrollamos las SRS debemos responder a las siguientes preguntas: ¿Cómo deben funcionar? y ¿Qué tan bien deben funcionar? las SIF que conforman el SIS.

Los requisitos funcionales describen que funcionalidad tiene la SIF, sin dejar duda del propósito de la misma y cuáles son las acciones necesarias para llevar y mantener el proceso en su estado seguro, tomando en cuenta, entre otras cosas, todos los modos de operación de
la planta (instalación, puesta en marcha, operación, mantenimiento, etc.), los peligros asociados al proceso que puedan afectar a la SIF y todas las condiciones ambientales a la cual estará expuesta. Aquí se responden a las siguientes preguntas: ¿Qué debe hacer la SIF?, ¿Cómo debe hacerlo?, ¿Cuándo debe hacerlo? y ¿Qué tan rápido?.

Los requisitos de integridad determinan el desempeño de los equipos que conforman la SIF y la arquitectura de votación de cada sub-sistema (elemento sensor, controlador lógico de seguridad y elemento final) que otorguen la disponibilidad y confiabilidad necesarias para que la función logre el SIL requerido. A su vez, hablar de integridad, implica garantizar que los equipos que conforman la SIF tengan la disponibilidad de responder en el momento que se produzca una demanda, y que se minimice la ocurrencia de disparos en falsos o disparos “espurios”. Respondiendo a la pregunta: ¿Qué tan bien debe actuar la SIF?

En general, los requisitos de seguridad del SIS y de sus SIF asociadas abarcan: requisitos funcionales, requisitos de integridad y confiabilidad, requisitos de operabilidad y mantenimiento, identificación de fallas y acciones de respuesta, intervalos de ensayos periódicos y requisitos para realizarlos, requisitos de interfaces entre el SIS y cualquier otro sistema, requisitos del programa de aplicación, entre otros.

Para finalizar, es importante resaltar dos puntos primordiales que no pueden faltar en el desarrollo de la SRS: La definición de la SIF y del estado seguro del proceso. Recordando que la definición de la SIF debe incluir: el elemento sensor (tag, descripción, arquitectura de votación y el punto de disparo), el elemento final tag, descripción, arquitectura de votación y la acción a realizar), lógica de actuación (relación entre la entradas y salidas de la SIF), el tiempo de ejecución de la SIF (tomando en cuenta el tiempo de seguridad del proceso) y el Nivel de Integridad de Seguridad (SIL) y/o el Factor de Reducción de Riesgo (FRR) requerido.

 Responda las preguntas de comprobación aquí:

 

¿Qué son las SRS? Leer más »

¿Se debe Considerar el Sistema de Detección de Fuego y Gas como una Función Instrumentada de Seguridad?

Sistemas de Seguridad con Requerimientos Especiales / /
Para responder esta pregunta es necesario definir el Sistema de Detección de Fuego y Gas (SDFyG). Un SDFyG es aquel diseñado e instalado para proteger contra los riesgos de fuga de gas (combustible, inflamable o tóxico) y fuego dentro de áreas monitoreadas; capaz de detectar el evento peligroso en su etapa incipiente, permitiendo tomar medidas inmediatas para su control y mitigación. La efectividad de este sistema, según el reporte técnico ISA TR84.00.07 y el Handbook de SFPE, se basa en tres (3) factores principales:
  • Cobertura de detección: Es la probabilidad que tiene el sistema de poder detectar el evento peligroso específico para el cual fue diseñado. Este factor es comúnmente descartado en las Funciones Instrumentadas de Seguridad (SIF), debido a que se da por sentado que el sensor tiene la capacidad de detectar la variable que está monitoreando (p.e. presión, temperatura, flujo, etc.), y solo fallaría en caso de problemas con la tubería de conexión, lo que usualmente es poco probable.
  • Disponibilidad de seguridad: Es la probabilidad de que el sistema actúe durante una demanda y está asociada al hardware. Se calcula de forma similar a la Probabilidad de Falla en Demanda Promedio (PFDavg) de una SIF, pudiendo utilizar las técnicas presentadas en el reporte técnico ISA TR84.00.02 considerando las tasas de falla aleatorias de los elementos sensores, controlador de lógica y los elementos finales; así como, las arquitecturas utilizadas para cada grupo de elementos, períodos de prueba, entre otros.
  • Efectividad de Mitigación: Es la probabilidad que tiene el sistema de reducir exitosamente las consecuencias del evento peligroso específico para el cual fue diseñado.
De conformidad con la norma IEC 61511: 2016, podemos decir que una SIF es aquella diseñada para alcanzar un Nivel de Integridad de Seguridad (SIL), con la intención de alcanzar y mantener un estado seguro para el proceso y trabajar en conjunto con otras capas de protección para la reducción de un riesgo específico.
En base a lo anterior, para que una Función de Seguridad (FS) del SDFyG pueda considerarse como una SIF, el mismo debe garantizar la detección del evento peligroso, alcanzar y mantener un estado seguro del proceso, estar definida para un riesgo en específico, tener asociado un SIL y, adicionalmente, debe poder definirse la Especificación de los Requisitos de Seguridad (SRS) (tiempo de respuesta, fallos de causa común, requisitos para las prioridades / las inhibiciones / los desvíos, entre otros); tal como lo establece la norma IEC 61511: 2016.
Los puntos que realmente marcan la diferencia entre una FS del SDFyG y una SIF están referidas a la capacidad de detección y la efectividad para reducir el riesgo, debido a que en el caso de un SDFyG existen muchos factores que afectan estas características; por lo que, generalmente es difícil garantizar que un SDFyG alcance y mantenga un estado seguro del proceso, así como generar una reducción de riesgo equivalente al menos de SIL 1 (10 – 100).
Entre los factores que afectan la posibilidad de que el evento peligroso se encuentre dentro del área de detección de un SDFyG, están:
  • Cambios en la dirección y velocidad del viento.
  • Puntos de ignición inesperados.
  • Objetos que desvíen el escape de material u obstaculicen el “campo de detección” del sensor.
  • Cantidad suficiente o insuficiente del material asociado a la fuga (tamaño de la nube o de la llama).
  • Inadecuado posicionamiento del sensor (distancia, altura, dirección e inclinación)
Algunos de los factores que influyen en la efectividad reducir el riesgo (o de la mitigación en este caso) son:
  • Falla del sistema automático de extinción de incendios.
  • Efectividad del método de extinción de incendios (polvo químico, agua, espuma, etc.).
  • Ocurrencia de un evento peligroso mayor al esperado.
  • Falla de la extinción manual de respaldo.
  • Afectación y vulnerabilidad del personal durante el combate del incendio.
  • Falla de la ventilación posterior a la extinción del incendio.
Para ilustrar lo antes dicho, presentamos un árbol de eventos con los factores que afectan el rendimiento de sistemas de detección de fuego y gas, considerando valores optimistas para la mayoría de los casos de detección, disponibilidad de seguridad y mitigación:
Tal y como se puede observar en el ejemplo, a pesar de usar equipos certificados y tener una disponibilidad de seguridad equivalente a SIL 2 (0,99 – 0,999), comúnmente obtenidos en el mercado, el factor de reducción de riesgos alcanzado por la FS del SDFyG es ligeramente mayor a 5, siendo menor que la banda inferior de SIL 1 (10 – 100). Este ejemplo refuerza lo antes dicho, es poco probable para la mayoría de los casos poder considerar las FS de los SDFyG como SIF, ya que es necesario que las mismas posean un nivel de desempeño elevado, el cual de acuerdo con los cálculos es una cobertura de detección y efectividad de mitigación superior a 0,90.
Sin embargo, existen excepciones en los cuales se podría considerar los SDFyG como SIFs, por ejemplo:
Una caseta de pintura, la cual impide la disipación de los gases inflamables y tóxicos, pudiendo alcanzar concentraciones potencialmente peligrosas dentro de la caseta. Una de las posibles acciones para proteger al personal contra este peligro, es tener un control de acceso, y alarma al detectarse altas concentraciones de gases inflamable y/o tóxicos. Es posible asumir que la cobertura de detección es cercana a 100% por encontrarse dentro de un área cerrada, y al realizar esta acción garantizaría que el personal no se vea afectado, siempre y cuando los dispositivos asociados al SDFyG funcionen de manera apropiada al momento de la demanda.
De forma general podemos decir que las funciones de seguridad asociadas a los SDFyG no deben ser consideradas como SIFs, salvo contadas excepciones, ya que los mismos no cumplen con todos los requisitos que exige la norma IEC 61511: 2016, siendo los más determinantes el no poder alcanzar y mantener el estado seguro del proceso; y la capacidad de detectar el evento peligroso específico para el cual se supone ha sido diseñado, lo que probablemente impedirá que alcance una reducción del riesgo en al menos un factor de 10 (SIL 1).
Se recomienda que los SDFyG tengan un Ciclo de Vida de Seguridad (CVS), dentro del cual el diseño sea realizado con un enfoque basado en desempeño. El usuario final debe garantizar que los mismos sean operados y mantenidos de forma que la reducción de riesgo que le ha sido asignada permanezca vigente durante toda su vida útil.

¿Se debe Considerar el Sistema de Detección de Fuego y Gas como una Función Instrumentada de Seguridad? Leer más »