SIS – Sistemas Instrumentados de Seguridad - Parte 3

Una visión práctica – Parte 3

La parte inicial el artículo es igual a la parte 1 hasta el ítem Ciclo de Vida de Seguridad

Hemos visto en el artículo anterior algunos detalles sobre Ingeniería de Confiabilidad. Veremos ahora, modelos usando sistemas en serie y paralelos, árboles de fallos (Fault Trees), modelo de Markov y algunos cálculos. 

Análisis de Fallos – Árbol de Fallos (Fault Trees)

Existen algunas metodologías de análisis de fallos. Una de ellas es bastante utilizada, el análisis del árbol de fallos (Fault Tree Analysis – FTA), que mira mejorar la confiabilidad de productos y procesos a través del análisis sistemático de posibles fallos y sus consecuencias, orientando la adopción de medidas correctivas o preventivas.

El diagrama del árbol de fallos muestra la relación jerárquica entre los modos de fallas identificados. El proceso de construcción del árbol se inicia con la percepción o previsión de un fallo, que es descompuesto y detallado en seguida en eventos más sencillos. De esa manera, el análisis del árbol de fallos es una técnica top-down, pues proviene de eventos generales que se desdoblan en eventos más específicos.

En seguida se ve un ejemplo de un diagrama FTA aplicado a un fallo en un motor eléctrico. El evento inicial, que puede ser un fallo observado o previsto, es llamado de evento de cumbre (o principal), y está indicado por la flecha azul. A partir de este evento se detallan otros fallos hasta alcanzar eventos básicos que constituyen el límite de resolución del diagrama. Los fallos mostrados en amarillo componen el límite de resolución de este diagrama.

Figura 1 – Ejemplo de FTA

Es posible adicionar al diagrama elementos lógicos, tales como ‘e’ y ‘o’, para caracterizar mejor el relacionamiento entre fallos. De esta manera es posible utilizar el diagrama para estimar la probabilidad de un fallo ocurrir a partir de eventos más específicos. El ejemplo siguiente muestra un árbol aplicado al problema de supercalentamiento en un motor eléctrico a través de elementos lógicos.

Figura 2 – Ejemplo de FTA usando elementos lógicos

El análisis de Árbol de Fallos fue desarrollado en el inicio de los años 60 por los ingenieros de Bell Telephone Company.

Símbolos Lógicos usados en la FTA 

La FTAes una representación gráfica de la interrelación entre los fallos de equipos o de operación que pueden resultar en accidente específico. Los símbolos vistos en seguida se usan en la construcción del árbol para representar esta interrelación. 

 

PUERTA “O”:indica que la salida del evento ocurre cuando hay una entrada de cualquier tipo.

 

 

PUERTA “E”:indica que la salida del evento solo ocurre cuando hay una entrada simultánea de todos los eventos. 

 

PUERTA DE INHIBICIÓN: indica que la salida del evento ocurre cuando sucede la entrada y la condición inhibidora está satisfecha. 

 

 

 

PUERTA DE RESTRICCIÓN:indica que la salida del evento ocurre cuando sucede la entrada y el tiempo específico de atraso o restricción terminó. 

 

 

EVENTO BÁSICO: representa el FALLO BÁSICO del equipo o fallo del sistema que no requiere otros fallos o defectos adicionales.

 

EVENTO INTERMEDIARIO: representa un fallo en un evento resultante de la interacción con otros fallos desarrollados a través de entradas lógicas como las arriba descritas. 

 

EVENTO NO DESARROLLADO: representa un fallo que no más se examina, porque la información no está disponible o porque sus consecuencias son insignificantes.  

 

EVENTO EXTERNO: representa una condición o un evento cuya existencia se supone ser una condición límite del sistema para análisis. 

 

TRANSFERENCIAS: indica que el árbol de fallos se desarrolla de manera adicional en otros fallos. Los símbolos de transferencia son indicados a través de números o letras.

 

Figura 3 – Símbolos Lógicos usados en FTA

Modelos de Markov

Un modelo de Markov es un diagrama de estatus donde se identifican los diversos estatus de fallo de un sistema. Los estatus se conectan por arcos identificados con las tasas de fallo o las tasas de reparo que llevan el sistema de un estatus a otro (vide figura 4 y figura 5). Los modelos de Markov son conocidos también como diagramas de espacio de estatus o diagramas de estatus. El espacio de estatus se define como el conjunto de todos los estatus donde el sistema puede ubicarse 

Figura 4 – Ejemplo de modelo de Markov

Para un determinado sistema, un modelo de Markov consiste en una lista de estatus posibles del sistema, los caminos posibles de transición entre los estatus y las tasas de fallos de esas transiciones. En el análisis de confiabilidad de las transiciones consisten generalmente de fallos y reparos. Al representar un modelo de Markov gráficamente, cada estatus es representado como un círculo, con flechas indicando los caminos de transición entre los estatus, como se ve en la figura 4.

El método de Markov es una técnica útil para modelar la confiabilidad de sistemas cuyos fallos son estadísticamente independientes y las tasas de fallo y reparo son constantes.

Se entiende como estatus de un componente el conjunto de posibles valores asumidos por sus parámetros. Estos parámetros son llamados variables de estatus y describen la condición del componente. El espacio es el conjunto de todos los estatus presentados por un componente.

El modelo de Markov de un verdadero sistema generalmente incluye un “full-up” del estatus (o sea, el estatus con todos los elementos operacionales) y un conjunto de estatus intermediarios que representan una condición de fallo parcial, llevando al estatus totalmente en fallo, o sea, el estatus donde el sistema es incapaz de desempeñar su función de proyecto. El modelo puede incluir caminos de reparo de transición, y también los caminos de transición de fallo. En general, cada camino de transición entre dos estatus reduce la probabilidad del estatus de que el está partiendo y aumenta la probabilidad del estatus donde está entrando, a una tasa igual al parámetro de transición multiplicada por la probabilidad actual del estatus de origen.

 El flujo de probabilidad total de un determinado estatus es la suma de todas las tasas de transición para ese estatus, multiplicándose cada uno por la probabilidad del estatus en el origen de esa transición. La salida de flujo probabilidad de un cierto estatus es la suma de todas las transiciones que salen del estatus multiplicados por la probabilidad de aquel determinado estatus. Para ilustrar, los flujos de entrada y salida típicos de un estatus y de estatus vecinos están representados en la figura 4.

En este modelo todos los fallos se clasifican como fallos peligrosos o como fallos seguros. Un fallo peligroso es lo que pone el sistema de seguridad en un estatus en el cual no estará disponible para detener el proceso en situación donde no existe peligro. El fallo seguro es normalmente llamado por “trip” falso o espurio.

Los modelos de Markov incluyen factores de cobertura de diagnóstico para todos los componentes y tasas de reparos. Los modelos consideran que los fallos no detectados serán diagnosticados y reparados por pruebas periódicas (proof  tests).

Los modelos de Markov incluyen aun tasas de fallos asociados a fallos funcionales y fallos comunes de hardware. El modelamiento del sistema debe incluir todos los tipos posibles de fallos y estos se pueden agrupar en dos categorías:

1. Fallos físicos
2. Fallos funcionales

Los fallos físicos ocurren cuando la función realizada por un módulo, un componente, etc., presenta un desvío en relación a la función especificada debido a la degradación física.

Los fallos físicos pueden ser fallos por envejecimiento natural o fallos provocados por el ambiente.

Para se utilizar los fallos físicos en los modelos de Markov débese determinar la causa de los fallos y sus efectos en los módulos, etc. Los fallos físicos débense categorizar  como fallos dependientes o independientes.

Fallos independientes son los que nunca afectan más de un módulo, mientras los dependientes pueden causar el fallo de varios módulos.

Los fallos funcionales ocurren cuando el equipo está en funcionamiento, aunque sin capacidad de realizar la función especificada debido a una deficiencia funcional o un error humano. Ejemplos de fallos funcionales son: errores de proyecto del sistema de seguridad, de software, de conexión del hardware, errores de interacción humana y errores de proyecto de hardware.

En los modelos de Markov los fallos de función se dividen en fallos seguros y fallos peligrosos. Se supone que un fallo de función seguro resultará en un trip espurio. De la misma manera, un fallo de función peligroso resultará en el estado de fallo-para-actuar, o sea, cuando es sistema no esté disponible para detener el proceso. La evaluación de la tasa de fallo de función debe tener en cuente muchas causas posibles, como por ejemplo:

1.   Errores de proyecto del sistema de seguridad

Se incluyen aquí errores de especificación lógica del sistema de seguridad, selección de arquitectura adecuada al sistema, selección incorrecta de sensores y actuadores, errores del proyecto de la interfaz entre los PLCs y los sensores y actuadores.

2.   Errores de implementación del hardware

Esos errores incluyen los que ocurren en la conexión de sensores y actuadores a los PLCs. La probabilidad de error aumenta con la redundancia de E/S. La utilización de sensores y actuadores redundantes también provocará una probabilidad mayor de errores de conexión.

3.  Errores de software

Esos errores incluyen los de software desarrollado  tanto por el proveedor como por el usuario. El software de proveedores incluye    típicamente el sistema operacional, las rutinas de E/S, funciones aplicativas y lenguajes de operación. Los errores de software del proveedor pueden minimizarse al asegurarse un buen proyecto y la observancia de los procedimientos de codificaciones y pruebas. La realización de pruebas independientes de otras organizaciones también puede ser de gran utilidad.

Los errores de software desarrollados  por el usuario incluyen el programa de aplicaciones, diagnósticos y rutinas de interfaz del usuario (displays, etc.). Ingenieros especialista en software de sistemas de seguridad pueden ayudar a minimizar los errores de software del usuario. Son necesarias también rigurosas pruebas con el software. 

4 .  Errores de interacción humana

Aquí se incluyen los errores de proyecto y de operación de la interfaz hombre-máquina del sistema de seguridad, los errores cometidos durante las pruebas periódicas del sistema de seguridad y durante el mantenimiento de módulos defectuosos del sistema. Los errores de mantenimiento pueden reducirse a través de un buen diagnóstico del sistema de seguridad que identifique el módulo defectuoso e incluya indicadores de fallos en los módulos defectuosos. Téngase en mente que no existe un diagnóstico perfecto o a prueba de fallos.

5. Errores de proyecto del hadware

Entre esos errores se incluyen los proyectos de fabricación de los PLC, sensores y actuadores y también los errores del usuario en la interfaz entre el sistema de seguridad y el proceso.

En configuraciones redundantes de PLC, sensores y elementos de actuación, se pueden reducir algunos fallos de funcionamiento a través de varios hardware y software.

Los fallos dependientes deben modelarse de manera distinta, pues existe la posibilidad de ocurrir fallos múltiplos simultáneamente. Del punto de vista del modelaje, los fallos dependientes dominantes son fallos de causa común. Los fallos de causa común resultan directamente de una causa básica común, siendo ejemplo la interferencia de radiofrecuencia que causa el fallo simultáneo de módulos múltiplos. El análisis de ese tipo de fallo es bastante complejo y requiere un profundo conocimiento del Sistema, tanto en el ámbito de hardware y de software cuanto del propio ambiente.

Figura 5 – Ejemplo de modelo de Markov en sistema redundante

Seguramente con equipos y herramientas certificadas cumpliendo con el estándar IED 61508 se conoce las tasas de fallos de los productos lo que facilita cálculos y arquitecturas de seguridad.

Conclusión

En términos prácticos el objetivo es reducir fallos y consecuentemente las paradas y riesgos de operación. Se busca el aumento de disponibilidad operacional y también de los procesos, la minimización  de variabilidad con consecuencia directa en el aumento de rentabilidad.

En los próximos artículos de esta serie veremos mas detalles sobre SIS. En la cuarta parte veremos un poco sobre el Proceso de Verificación de SIF.

 Referencias

• IEC 61508 – Functional safety of electrical/electronic/programmable electronic safety-related systems.
• IEC 61511-1, clause 11, " Functional safety - Safety instrumented systems for the process industry sector - Part 1: Framework, definitions, system, hardware and software requirements", 2003-01
• William M. Goble, Harry Cheddie, "Safety Instrumented Systems Verification: Practical Probabilistic Calculation"
• ESTEVES, Marcello; RODRIGUEZ, João Aurélio V.; MACIEL, Marcos. Sistema de intertravamento de segurança, 2003.
• Sistemas Instrumentados de Segurança - César Cassiolato
• “Confiabilidade nos Sistemas de Medições e Sistemas Instrumentados de Segurança” - César Cassiolato
• Sistemas Instrumentados de Segurança – Uma visão prática – Parte 2, César Cassiolato
• http://www.numa.org.br/conhecimentos/conhecimentos_port/pag_conhec/FTA.htm