Invitado

¿Por qué es necesario tener un Sistema de Gestión de la Seguridad Funcional?

Gestión de la Seguridad Funcional / /

Es muy común que hoy en día, se tome a la ligera la elaboración de productos de ingeniería relacionados con Seguridad Funcional. Por ejemplo, realizar un HAZOP o un LOPA.

Generalmente, las compañías que realizan este tipo de estudios, o algún otro producto relacionado con Seguridad Funcional, disponen de personal capacitado para realizar los mismos; pero ¿Es esto suficiente? La respuesta, es no. Si se desea cumplir con lo que establece la norma IEC 61511: 2016, el personal calificado no es suficiente, es necesario que la organización posea un Sistema de Gestión de Seguridad Funcional. Esencialmente, para que exista conformidad con la norma IEC 61511, se debe demostrar que se cumplieron todos sus requerimientos.

La cláusula 5 “Gestión de la Seguridad Funcional” establece en su inciso 5.2.5.2 que las compañías que estén involucradas en una o más actividades relacionadas con el Ciclo de Vida de Seguridad Funcional deberán poseer un Sistema de Gestión de Calidad. Adicionalmente, este inciso nos señala que, si alguien contrata a alguna compañía para realizar alguna actividad, y se desea demostrar conformidad con la norma, la compañía que preste los servicios relacionados con los Sistemas Instrumentados de Seguridad, deberá poseer un Sistema de Gestión en Seguridad Funcional. Pero, es probable que alguna compañía, que desee demostrar conformidad con la norma IEC 61511, pueda utilizar, o bien respaldarse, en su Sistema de Gestión de Calidad debido a que muchos de los requisitos de la norma ya pueden estar contemplados en el Sistema de Gestión de la Calidad.

No es un simple capricho el necesitar un Sistema de Gestión de Seguridad Funcional. Se puede realizar un HAZOP de manera impecable y cumpliendo con lo que establece la cláusula 8 de la norma IEC 61511, por ejemplo. Pero, en un Sistema de Gestión de Seguridad Funcional se debe contemplar las competencias del personal. Esto quiere decir que, los elaboradores deberán cumplir con un mínimo de competencias y habilidades para llevar a cabo con éxito la actividad. Por ejemplo, si hablamos de la descripción de las competencias de un Líder HAZOP, seguramente se necesite a una persona que sea ingeniero (de preferencia Químico – no limitativo), que tenga experiencia comprobable en la asistencia a Estudios de Identificación de Peligros, con cualidades de liderazgo y maneje muy bien la metodología, entre otras. En este punto, lo más importante es que el Sistema de Gestión defina de forma concreta y precisa qué competencias debe tener esta persona, así como todas las personas que estarán involucradas.

En cuanto a la realización de la actividad en sí, la misma deberá estar planificada. Debe existir un plan que indique el tiempo estimado de la actividad y los recursos que se necesitarán para llevarla a cabo con éxito. Por ejemplo, si hablamos de un HAZOP, los tiempos para la preparación del estudio, su ejecución, así como la elaboración del reporte deberán ser estimadas. Para esto, el Plan de Gestión deberá contemplar cómo se estimarán estos tiempos en función de la complejidad del proceso. De igual forma, definir cuáles recursos se necesitarán, como son los programas, computadoras, salas de reuniones, proyectores, entre otros.

La documentación generada luego de realizada una actividad, deberá cumplir con lo indicado en la cláusula 19 de la norma IEC 61511. Debe ser precisa, fácil de entender, formalmente correcta (título, autor, fecha, índice de revisión), estar disponible y ser accesible. Si la documentación cumple con todo lo anterior, las actividades de Verificación, Evaluación y Auditoría podrán realizarse de manera efectiva.

La Verificación nos dirá si se cumplieron con los objetivos y requisitos de la actividad realizada, según establezca la cláusula correspondiente. La Evaluación emitirá un juicio sobre si se alcanzó o no la Seguridad Funcional y la Auditoría nos podrá decir si los procedimientos han sido bien aplicados, y si están actualizados. Para realizar cualquiera de estas actividades, se deberá contar con procedimientos y designar el personal calificado.

En conclusión, un Sistema de Gestión de la Seguridad Funcional asegura que toda actividad o servicio que se realice en el marco de la norma IEC 61511:2016, cumpla con todos los objetivos y requisitos, para garantizar que la Seguridad Funcional sea alcanzada y mantenida durante el Ciclo de Vida de un proyecto.

¿Cree Ud. que necesita tener un Sistema de Gestión de la Seguridad Funcional?

Eduardo Sánchez

FSEng TÜV SÜD TP18051531

Romel Rodríguez

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

¿Por qué es necesario tener un Sistema de Gestión de la Seguridad Funcional? 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 »

Alarmas, del mímico a la nube

Sistemas de Seguridad con Requerimientos Especiales / /

Antes de la adopción de sistemas de control distribuido (DCSs) y otras interfaces hombre-máquina automatizadas (HMis), las indicaciones de las operaciones y alarmas en las plantas de proceso eran básicas, poco explicativas y estaban restringidas debido a limitaciones de espacio y tecnología. En su mayoría, las interfaces de procesos consistían en un panel o mímico instalado en la Sala de Control al que llegaban señales desde el área de procesos (a través de cables o tuberías) y encendían unas pequeñas lámparas o bombillos para generar la indicación de una condición determinada.

Cada punto de alarma debía ser cableado individualmente desde el sensor de campo; por lo que, diseñar, operar o hacer un cambio en un sistema con tan pocas facilidades era sumamente engorroso, implicaba un alto costo y el riesgo de dañar otras alarmas o indicaciones del proceso. ¡Cualquier persona lo pensaba dos veces antes de incluir o modificar una alarma!

Luego, con la implementación de los sistemas automatizados (que permiten realizar cambios y adiciones por software) el número de alarmas que pueden ser configuradas en un sistema se incrementó hasta el punto de ser virtualmente ilimitado. Es decir, el proceso pasó
de cablear, conectar puntos eléctricos, instalar tuberías, modificar de tableros y muchas horas de trabajo, a abrir un programa e ingresar el nuevo valor de la alarma.

Actualmente, las tendencias tecnológicas de globalización e interconexión de sistemas van dirigidas, incluso, a usar la nube para mantenernos informados. Este modelo, accesible y sencillo de usar, proporciona sin dudas una oportunidad de mejorar los sistemas de alarmas, pero también puede hacer que la gestión de alarmas sea una tarea desafiante. Muchas cosas pueden salir mal si no ponemos la debida atención en el proceso de seleccionar, implementar y mantener las alarmas de nuestros sistemas de control y seguridad. Solo para tener una idea, veamos algunos ejemplos:

a) Usar las alarmas que por defecto traen configurados los sistemas de control para cada canal de I/O, puede generar una gran cantidad de notificaciones innecesarias en las consolas de operación, causando confusión y posibles errores operacionales.

b) Utilizar valores genéricos para facilitar el proceso, digamos 90% del rango para alarma de alta, sin tomar en cuenta las condiciones específicas de cada variable, puede dejar una cantidad importante de alarmas inútiles o alarmas de condiciones sobre las cuales el operador no puede hacer nada al respecto; bien sea porque no tiene tiempo suficiente para actuar o no tiene las herramientas necesarias para cambiar la situación.

c) No tomar en cuenta el ajuste de los valores de las alarmas, en los procesos de manejo del cambio.

En resumen, hoy en día es tan fácil configurar una alarma que nos exponemos a crear un sistema sobresaturado de información que, en muchos casos, se desvía de su función; en lugar de ser una ayuda para el operador, termina siendo un factor de contribución de accidentes con consecuencias de importancia.

Existe una necesidad de volver a lo esencial y mantener los sistemas tan simples como sea posible, para lo cual las normativas ISA/ANSI 18.2 e IEC 62682 han realizado esfuerzos importantes. En ese sentido, quisiéramos recordarles varios básicos que nos permitan mantener la simplicidad de los sistemas.

En primer lugar, recordemos que una alarma es un medio audible y/o visible para indicar al operador el mal funcionamiento de un equipo, una desviación del proceso o cualquier condición anormal que requiera una respuesta. Esto significa que una alarma es más que un mensaje o un evento, ya que indica una condición que exige una acción rápida del operador. Cada alarma debe estar asociada a un escenario peligroso (causa – consecuencia); requerir una acción específica y brindar tiempo suficiente al operador para ejecutar la acción correspondiente. Idealmente, cada alarma debe indicar su prioridad, posible causa raíz y un procedimiento de respuesta recomendado; así el operador podrá actuar rápida y eficazmente.

La próxima vez que esté en el proceso de crear una alarma, le recomendamos que intente verificar si la misma cumple con todas las características que menciónanos a continuación:

  • Relevante: Debe tener un valor operativo.
  • Única: No debe estar duplicada por otra alarma.
  • Oportuna: La activación de la alarma no debe ocurrir mucho antes de que la respuesta del operador sea necesaria, o demasiado tarde para poder responder a la alarma.
  • Priorizada: Se debe indicar la importancia de que el operador responda a la alarma.
  • Comprensible: Debe tener un mensaje claro y fácil de entender.
  • Funcional: Debe identificar el problema que ha ocurrido.
  • Indicativa: Debe mostrar la acción que debe ejecutar el operador.
  • Precisa: Debe llamar la atención sobre las condiciones más importantes.

La observancia de estos aspectos básicos le permitirá generar alarmas que realmente soporten las actividades del operador y, en consecuencia, crear mejores sistemas de alarmas.

Recuerde, “manténgalo simple”.

 

«La simplicidad es la máxima sofisticación.»

Leonardo Da Vinci, polímata florentino del renacimiento

 

 

Anakarelys Díaz

FSEng TÜV SÜD TP18051528

Romel Rodríguez

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

 

Alarmas, del mímico a la nube Leer más »

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

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

Las Capas de Seguridad, no sólo es una cuestión de superhéroes

Asignación del SIL / /
En el mundo de la seguridad de los procesos existe una gran variedad de literatura indicando mejores prácticas (experiencias para el desarrollo y diseño de proyectos) y definiciones de términos para lograr que los procesos obtengan un nivel de conformidad respecto a la seguridad funcional. Uno de los temas importantes en la gestión de la seguridad funcional, para el desarrollo de un sistema de seguridad, es la definición de las Capas de Protección y su capacidad de disminuir el riesgo. No basta con tomar un elemento, equipo, sistema o procedimiento y designarlo como una capa, esto no le da el superpoder de la protección.
Por definición, las Capas de Protección son: “Cualquier mecanismo independiente que reduzca el riesgo por control, prevención o mitigación. Puede ser un mecanismo de ingeniería de procesos, tales como el tamaño de los recipientes que contienen químicos peligrosos, un mecanismo mecánico como una válvula de alivio, un SIS (Sistema Instrumentado de Seguridad) o un procedimiento administrativo como un plan de emergencia contra un peligro inminente. Estas respuestas pueden ser automatizadas o iniciadas por acciones humanas.” IEC 61511:2016-3.2.57
Las Capas de Protección asociadas al proceso son identificadas en la etapa de análisis, durante el desarrollo de los estudios de Análisis de Peligros y Riesgo. Luego, durante los estudios de Asignación de las Funciones de Seguridad a las Capas de Protección se define la capacidad que tienen las mismas para lograr la reducción de riesgo. Es en esta fase donde se cuantifica el valor o “superpoder” identificado en la fase anterior y que, en lugar de utilizar un criterio subjetivo como en el caso de los superhéroes, se debe verificar qué poder es el mejor para cada situación de peligro (claro está, para los de la vieja escuela a menos que sea Superman que prácticamente los tiene todos). Así, para cada escenario de riesgo existirá una capa de protección, comportando como superhéroe para salvar el día.
Para que una Capa de Protección pueda ser ese superhéroe, debe ser por lo menos:
Específica, es decir, diseñada para la condición de peligro que se quiere evitar, así como una Válvula de Alivio de Sobrepresión (PSV) no nos serviría mucho en el caso de un escenario de muy alto nivel, tanto así no nos ayudaría Aquaman en un peligro extraterrestre en el espacio exterior.  
Efectiva, para que por sí sola sea capaz de detener la cadena de eventos que llevan a la consolidación del escenario de riesgo y llevar al proceso a un estado seguro. Una válvula PSV diseñada para alivio térmico poco servirá para un escenario de sobrepresión para descarga bloqueada o fuego externo, tanto como Flash para levantar un gran peso.
Independiente, de la causa del evento iniciador del escenario de riesgo como de las otras Capas de Protección. Una alarma configurada en el controlador del lazo de control que genera la condición de peligro posiblemente no servirá de mucho para detener el problema, tanto como si le pidiéramos ayuda a Lex Lutor.
Auditable o comprobable, es decir, que la Capa de Protección pueda demostrar la capacidad de reducción de riesgo que se le asigna. Podemos probar una PSV y hemos visto la capacidad de cada superhéroe en su misión dando fe de sus capacidades. No importa que cada elemento, equipo, sistema o procedimiento identificado como salvaguarda durante el Análisis de Peligros y Riesgo sea un superhéroe, debe haber un superhéroe adecuado para cada misión.
Durante el Estudio de los Riesgos de los Procesos se debe estar consciente que el desconocimiento o falla en la definición las capas de protección y la capacidad de las mismas para la reducción de riesgos pueden ocasionar eventos muy peligrosos, no necesariamente la destrucción de la mitad del universo por Thanos, pero puede conllevar a la ocurrencia de un evento fatal.
Gerardo Salazar
FSEng TÜV SÜD TP18051530
Romel Rodriguez
Functional Safety Expert TÜV SÜD TP18010990 | ISA84/IEC 61511 Expert | FSEng TÜV Rheinland 575/07 | PHA Leader

Las Capas de Seguridad, no sólo es una cuestión de superhéroes 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 »