IEC 61511

IEC 61511: 10 cosas que debes saber de la norma

Principios Básicos / /

Hoy hemos escogido un decálogo de cosas que, en nuestro parecer, debes saber sobre la norma IEC 61511. Intentaremos, en forma muy breve, abordar los tópicos más comunes basados en: a) la importancia que para nosotros tiene el entendimiento del espíritu de la norma, b) requisitos nuevos que no han sido suficientemente difundidos y, c) preguntas frecuentes de nuestros clientes.

1. Entre tantas normas, ¿cómo saber si esta IEC 61511 es para mí?

Esta es una norma específica para el sector de procesos asociados con la producción, generación, manufactura y/o tratamiento de petróleo, gas, madera, metales, alimentos, plásticos, petroquímicos, productos químicos, vapor, energía eléctrica, productos farmacéuticos y materiales de desecho. Es relativa solo a la Seguridad Funcional de los SIS, no debe confundirse con la seguridad global del proceso; ésta es solo la parte de la seguridad que proporciona el automatismo asociado al SIS, incluyendo su hardware y su programa de aplicación.

2. Medir para controlar. Una norma basada en desempeño

El desempeño como eje central del diseño (y la operación posterior del SIS), es el principal elemento diferenciador con respecto a otras normas relacionadas con la seguridad; por ejemplo, API 14C o NFPA 82 por mencionar algunas. El desempeño está relacionado a la brecha entre qué riesgo estoy dispuesto a asumir (riesgo meta) y el riesgo que estimo está relacionado a un peligro específico que ha sido identificado.

Recordemos que, no puede existir una Función Instrumentada de Seguridad (SIF) que no esté relacionada a un peligro específico; ya que, es a partir de la identificación de una necesidad de protección que se especifica una solución automatizada que genere una reducción de riesgo. La norma IEC 61511 dispone de una métrica de desempeño representada por el Nivel de Integridad de Seguridad (SIL) que, en cierta medida, indicará proporcionalmente de cuánto riesgo estoy dispuesto a dejar descansar sobre los hombros de cada SIF. Esa métrica tiene unos objetivos numéricos bien definidos que son, la Probabilidad de Falla Promedio (PFDavg) o Probabilidad de Falla Por Hora (PFH) que representan las fallas aleatorias permitidas para un determinado nivel de integridad.

3. Cómo trabajar la Seguridad Funcional? El Ciclo de Vida de Seguridad al rescate

La norma IEC 61511 declara un Ciclo de Vida de Seguridad del SIS (CVS) con actividades bien definidas y una colección de requisitos (más de 700, todos de estricto cumplimiento) para que el SIS logre alcanzar la Seguridad Funcional. El CVS es una de las principales herencias de esta norma, el seguimiento del CVS es fundamental para minimizar las fallas sistemáticas que son introducidas por nuestra forma de trabajar.

El CVS define cada fase en actividades de entrada, salidas y actividades de verificación, que deben ser realizadas en un orden específico. Es muy importante entender que, el CVS es particular de cada involucrado en la vida del SIS; por ejemplo, el CVS del integrador será diferente al de quien hace la ingeniería y también al del usuario final.

4. El control de lo que se hace y la Gestión de la Seguridad Funcional

Gestionar es poner a la gente correcta a realizar el trabajo correcto, con las herramientas necesarias y el tiempo adecuado. Para esto, debe existir una figura responsable de la Seguridad Funcional en general, que asegure que las actividades alrededor del SIS se realizan en forma consistente. Un punto de relevancia es la relativa al personal, no se trata necesariamente de crear una nueva estructura organizativa, es simplemente asignar las responsabilidades claramente dentro de la organización. Además, evaluar las capacidades, comunicar las responsabilidades asignadas, velar porque las personas realmente tengan las competencias para realizar el trabajo y disponer de los procedimientos para hacer (o supervisar) los trabajos relacionados al SIS (sino cada uno lo hará a su manera creando caos e inconsistencias).

Finalmente, un sistema de gestión nos brindará el soporte necesario para que el trabajo esté de conformidad con la norma. Algo curioso, es que cuando solicitamos equipos certificados, estamos pidiendo la comprobación, por un tercero independiente, de que quien fabrica el dispositivo lo hace dentro del marco de un sistema de gestión de conformidad con la norma (en este caso IEC 61508). Entonces, por qué no hacemos lo mismo al contratar proveedores de servicios o nos preocúpanos por crear ese marco de gestión en nuestras propias organizaciones?

Contenido relacionado: Trabajando en Seguridad Funcional: La gestión como herramienta para evitar las fallas sistemáticas

5. Mi SIS ya estaba aquí cuando yo llegué y no estoy seguro de que esté acorde a la norma

Lo primero que debemos saber es que para un SIS diseñado y construido de acuerdo con códigos, estándares o prácticas publicadas antes de la emisión de la norma IEC 61511, el usuario final debe determinar que el sistema está diseñado, mantenido, inspeccionado, probado y operando de manera segura. Esto es algo que ya hemos visto en el CFR 29 de OSHA y en lo que se llamaba la clausula del abuelo de ISA 84 (antes de la unificación de las normas ISA e IEC en 2018).

Así que quedan dos caminos, o adoptamos la norma con todo lo que esta implica o nos dedicamos a demostrar (soportes en mano) que el SIS existente brinda la reducción de riesgo que de él se espera en forma efectiva. Como ven, decir que no hace falta hacer nada no es una opción.

6. El personal debe ser ¿competente o certificado?

No se espera que exista un super ingeniero, solo se espera que sea competente para realizar las tareas del CVS que le corresponden. Una certificación, por parte de un tercero independiente, da fe que la persona posee una competencia particular (bien sea de conocimiento o de experiencia) pero esa palabra nunca lo encontrará en esta norma. Lo que si encontrará es que se debe establecer un procedimiento para gestionar la competencia de todos los implicados en el ciclo de vida del SIS y que se deben realizar evaluaciones periódicas. Esto es que las competencias deben ser desarrolladas, evaluadas y refrescadas en forma continua.

A menudo perdemos de vista que la competencia es más que conocimiento o formación académica, y que tienen un peso, igual de importante, la práctica continua de lo que se sabe, la actitud hacia el trabajo y las habilidades del individuo para hacer, en forma adecuada, una tarea específica.

Contenido relacionado: Trabajando en Seguridad Funcional: La Gestión de las Competencias del Personal

7. Es cierto eso que dicen que el SIS debe ser independiente del BPCS

La norma IEC 61511 establece claramente que el SIS es el único sistema que puede alojar a una SIF y que el BPCS (al menos que se diseñe según la norma) no debería alojar funciones instrumentadas de seguridad. La independencia y separación tiene muchas aristas en esta norma y todas atienden a minimizar las fallas de causa común y, para ello, se aborda este tema buscando minimizar la interferencia o lo propagación de fallas de un sistema a otros.

La norma indica la necesidad de estudiar: a) la independencia entre capas de protección; b) la diversidad entre capas de protección; c) la separación física entre diferentes capas de protección y d) los fallos de causa común entre capas de protección y entre capas de protección y BPCS. La independencia no es necesariamente separación física, más bien se refiere a independencia probabilística, es decir, determinar que las causas de falla de causa común sean suficientemente bajas como para afectar la integridad.

La independencia en la norma va más allá de solo HW y SW, también es mencionada como medida de control de actividades de gestión como evaluaciones, auditorías y verificaciones que requieren un cierto grado de imparcialidad.

Recuerde, mientras el SIS sea más simple es mejor, puede ser un gran dolor de cabeza tratar de justificar el hecho de compartir elementos con el BPCS, sobre todo después de un accidente.

8. Del papel a la acción. Seguimiento del desempeño del SIS

Se debe asegurar que el SIS mantiene las condiciones de diseño, es decir todas las premisas de diseño deben ser validadas durante la operación y mantenimiento (O&M) del SIS. Para esto, debemos crear una colección de indicadores (KPI) que nos permitan medir el desempeño. Aquí es importante hacer una buena selección de KPI que sean representativos de nuestras propias operaciones y no tratar de hacer lo que otros hacen. Se debe estar alerta a todas las fuentes de degradación. Las inspecciones en campo de los elementos que conforman el SIS toma especial importancia para esto. Se debe vigilar el efecto de las condiciones ambientales, de las propias condiciones del proceso y de la manera que el personal de O&M se relaciona con el SIS.

Debemos medir y analizar el comportamiento de las tasas de fallas usadas en el diseño, ya que eso es la base del modelo con el que creamos nuestro SIS y, como modelo al fin, es la mejor representación que pudimos hacer en un momento determinado; por lo que, validarlo es esencial. El modelo del que hablamos se relaciona con una realidad circundante y se ajustó a las suposiciones de esa realidad, por lo tanto, tiene la misma importancia verificar que el comportamiento del proceso es tal cual lo visualizamos durante el diseño. Una mayor tasa de demanda puede hacer que nuestro SIS nos brinde una sensación falsa de seguridad.

9. Yo no diseñé ese sistema, yo soy Operador y/o Mantenedor

En la norma IEC 61511 solo existen un par de páginas dedicadas a indicar qué se debe hacer en la fase de O&M, y aunque parezca poco, en realidad es mucho trabajo. Hablamos de una etapa que puede durar más de 20 años y que requieren de un alto nivel de compromiso y mística de trabajo. Como dijimos anteriormente, se debe entender el impacto de la interacción del personal de O&M sobre la integridad del SIS. Es muy importante que el personal de operaciones entienda de qué peligros específicos le protege el SIS y cómo un fallo de éste compromete su seguridad; además, de las acciones que debe realizar como medida de compensación.

La gestión de los desvíos (bypass) tiene especial importancia en la nueva versión de la norma; un Operador consciente de los peligros de los cuales es protegido por el SIS será menos propenso a colocar en bypass a las SIF y será mucho más cuidadoso en su uso. Por otro lado, el personal de mantenimiento debe saber cómo es que el Tiempo de Inspección de la SIF afecta su integridad. Saber que hay una relación inversamente proporcional entre el tiempo de pruebas de las SIF y su capacidad de proteger. Por último, debemos hacer una campaña de sensibilización para hacer entender al personal de O&M la importancia que tiene sus opiniones, requisitos y decisiones en la etapa de diseño.

10. Mi SIS está aislado, no necesito otro problema como la seguridad cibernética

Las nuevas facilidades de intercambio de datos de los sistemas más modernos traen consigo también un nuevo grado de exposición y vulnerabilidades, inclusive los menos interconectados no están exentos de una amenaza.

La última versión de la norma indica, ya en forma explícita, la necesidad de identificar qué posibles vulnerabilidades puede tener nuestro sistema, ahora desde el punto de vista de la seguridad (física y cibernética). Un accidente provocado por una falla aleatoria puede ser también originado de forma intencional al explotar una vulnerabilidad de seguridad de un SIS y de ahí la necesidad de contemplar esto en nuestro análisis.

Para la norma no basta con identificar las vulnerabilidades, el SIS debe ser inmune a este tipo de amenazas; por tanto, el diseño debe contemplar lo que sea necesario. Al adentrarnos en este tipo de temas, vemos que las amenazas son sumamente cambiantes, por lo que, nada es estático en el mundo de la ciberseguridad. Todos los días hay una actualización de una contramedida porque responde a una nueva amenaza. Por ejemplo, la actualización de antivirus o firmwares. Así estos nuevos requisitos implican hacernos de nuevas competencias, para entender cómo se podría ver afectado el SIS.

A manera de conclusión podemos decir que, conocer los requisitos de la norma IEC 61511 nos ayudará a entender nuestras responsabilidades y nos permitirá realizar mejor nuestro trabajo, manteniendo la integridad de los SIS en cualquier fase del Ciclo de Vida de Seguridad.

IEC 61511: 10 cosas que debes saber de la norma Leer más »

¿Cómo implementar un bypass sin afectar la seguridad?

SRS / /

Como les comenté en el blog anterior Bypass, muchos nombres ¿mismo fin? los bypass son una de las facilidades que permiten realizar las actividades de mantenimiento u operación del Sistema Instrumentado de Seguridad (SIS) o alguna de sus Funciones Instrumentadas de Seguridad (SIF).

En esta oportunidad les hablare sobre los requerimientos de la norma IEC-61511 para asegurar que, al implementar los bypass, estos sean especificados, diseñados, instalados, operados y mantenidos de manera que no comprometan la seguridad del sistema.

El primer punto en el que se hace referencia a los bypass es en la fase de Especificaciones de los Requerimientos de Seguridad del SIS (SRS) (Clausula 10, IEC-61511:2016), donde se establece que se deben “Definir los requisitos para los desvíos de la SIF, incluyendo procedimientos escritos que deben ser aplicados en la operación de los mismos. Además, describir el control administrativo y también la forma en que serán activados y desactivados”.

Este es el punto de partida para definir los bypass, describiendo todos los requerimientos a tomar en cuenta para su diseño, pruebas y operación, como, por ejemplo: arquitectura de votación cuando la SIF posee un bypass, alarmas en el sistema por activación del bypass, procedimientos para su aplicación, entrenamientos del personal involucrado, controles administrativos, registros de bypass realizados, autorizaciones para realizar el bypass, auditorias periódicas, entre otros.

Posteriormente, los bypass son contemplados en la fase de Diseño del SIS (Clausula 11, IEC-61511:2016) donde se establece:

  • Para el diseño de la Interfaz de Operación se debe contemplar:
    • Protección de seguridad de acceso a los bypass (mediante llave, contraseñas, procedimientos, etc.) para evitar su uso no autorizado.
    • Indicación cuando una función de seguridad o cualquier parte del SIS se encuentra es estado de bypass del SIS.
  • El diseño de la interfaz de mantenimiento / ingeniería también debe proporcionar la protección de seguridad de acceso donde se requieren bypass. Además, los bypass deben instalarse de modo que las alarmas y las instalaciones de parada manual no estén desactivadas.
  • Se puede considerar límites de tiempo para la operación de los bypass y limitar el número de bypass que pueden estar activos, por ejemplo, si se el grupo del elemento sensor posee una arquitectura de votación 2oo3 solo es posible realizar 1 bypass a la vez y degradar la función a 1oo2, de lo contrario se deberá llevar el proceso al estado seguro (disparo de la SIF).
  • Se debe definir el tiempo máximo en que el SIS puede estar en bypass (reparación o prueba) mientras se continúa la operación segura del proceso.
  • Se deben proporcionar medidas compensatorias que garanticen una operación segura cuando el SIS está en bypass (reparación o prueba).

Es importante aclarar que el funcionamiento seguro de la instalación, en caso de aplicación de un bypass, dependerá de la aplicación oportuna de medidas de compensación o acciones que brinden seguridad y compensen la reducción de riesgo que se perdió al colocar la función en bypass. Un ejemplo sería que el operador monitoree la señal de un instrumento en campo (diferente al que está en bypass) hasta que el equipo se encuentre operativo. En este caso, adicionalmente, se deberá disponer de un medio manual, para que el operador pueda actuar y llevar el proceso al estado seguro, si se presentase una demanda en el proceso.

  • El forzado de entradas y salidas del SIS no debe usarse como parte de los programas de aplicación, procedimientos operativos y  mantenimiento excepto que el SIS se encuentra fuera de servicio o que se complemente con procedimientos y controles de seguridad de acceso. Cualquier force deberá ser anunciado o activar una alarma, según corresponda.

En la fase de Validación de Seguridad del SIS (Clausula 15, IEC-61511:2016) se establece que “Las pruebas de validación deben incluir la verificación del correcto funcionamiento de las funciones de bypass y de las inhibiciones o anulaciones de arranque y operacionales (SOS / POS)”. Además, “Después de la validación del SIS y antes de que los peligros identificados estén presentes, se llevarán a cabo las actividades para que todas las funciones de bypass sean regresadas a su posición normal incluyendo las inhibiciones, anulaciones y permisos de forcé”.

Por último, en la fase de Operación y Mantenimiento (Clausula 16, IEC-61511:2016) se indican los requerimientos que deben ser considerados por los operadores y en procedimientos operacionales:

  • Los procedimientos de operación y mantenimiento deben:
    • Proporcionar las medidas de compensación y restricciones necesarias cuando el sistema está en bypass, para prevenir un estado inseguro y / o reducir las consecuencias de un evento peligroso. Las medidas compensatorias se deben establecer con los límites de operación asociados (duración, parámetros del proceso, etc.).
    • Indicar información sobre los procedimientos que se aplicarán antes y durante el bypass y lo que se debe hacer antes de la eliminación del bypass y el tiempo máximo permitido para estar en el estado de bypass.
    • incluir la verificación de que los bypass son eliminados después de los ensayos periódicos.
  • La operación continua del proceso con un dispositivo SIS en bypass solo se permitirá si un análisis de riesgos ha determinado que existen medidas compensatorias y que proporcionan una reducción adecuada del riesgo. Los procedimientos operativos se desarrollarán en consecuencia.
  • Los operadores deben estar capacitados para la operación y administración correcta de todos los interruptores de bypass / anulación del SIS y bajo qué circunstancias se deben utilizar estos bypass.
  • El estado de todos los bypass se registrará en un registro de bypass.
  • Las piezas de repuesto del SIS deben identificarse y ponerse a disposición para minimizar la duración de los bypass por falta de disponibilidad de repuestos.

Ahora, si bien los bypass se usan comúnmente para permitir que se realice un trabajo esencial, debemos tener en cuenta que cuando se aplica un bypass, el SIS (o la SIF) estará inhabilitado para ejercer su función, es decir no proporcionará la reducción de riesgos y fiabilidad que de él se requiere por lo que es importante saber lo que debemos hacer. Es nuestra responsabilidad seguir las normas y buenas prácticas que nos ayuden a diseñar facilidades, procedimientos y herramientas necesarias para un uso efectivo de este tipo recursos.

En el próximo blog hablaremos acerca de las políticas de uso de bypass y la operación segura de los mismos.

¿Cómo implementar un bypass sin afectar la seguridad? Leer más »

Bypass, muchos nombres ¿mismo fin?

SRS / /

Cuando diseñamos una Función Instrumentada de Seguridad (SIF) lo hacemos con el propósito de cubrir una brecha de riesgo y deseamos que siempre esté disponible para protegernos en el momento en que se presente una demanda del proceso. Pero, la verdad es que existen condiciones donde necesitamos sacar de servicio algunas SIF en forma temporal, como en la puesta en marcha, mantenimiento, parada de proceso, entre otros.

Bypass es uno de los términos más usados al realizar esta operación, pero existen otras denominaciones. Por mencionar algunos tenemos el SOS (Start up Override Switch), POS (Process Override Switch), MOS (Maintenance Override Switch), derivación, inhibición, “override”, “force”, “defeat”, entre otros. Aunque son términos frecuentemente utilizados, muchas veces no tenemos claro el significado de cada término y la confusión al momento de aplicarlos puede resultar en errores en el diseño, configuración, operación, que terminarán comprometiendo la seguridad del proceso.

¿Son sinónimos?, ¿se diferencian en el modo de aplicación (vía hardware o software) ?, ¿dependen de las condiciones del proceso (arranque, mantenimiento, etc.)?

La norma IEC-61511 define bypass como la “acción o facilidad para evitar que se ejecute toda o parte de la funcionalidad de una SIF o el SIS”. Algunos ejemplos de aplicaciones de bypass en una SIF pueden ser:

  • Bloqueo de la señal de entrada en la lógica de disparo, mientras aún presenta  los parámetros de entrada y la alarma al operador.
  • Se mantiene en estado normal la señal de salida de la lógica de disparo del elemento final, lo que impide que la función ejecute su acción a través del elemento final.
  • Se proporciona una línea de derivación física alrededor del elemento final (válvula de bypass).
  • Se selecciona un estado predeterminado de un elemento (por ejemplo, entrada de encendido / apagado).
  • Se usa un valor de entrada o salida en una lógica mediante una herramienta de ingeniería (por ejemplo, en el programa de aplicación).

Ahora, ¿de qué depende la forma en que aplicamos un bypass?

Lo primero que se debe hacer al momento de pensar en colocar una facilidad de bypass a una SIF, es saber el propósito del mismo y la forma en que será implementado. Por esto, mi recomendación es que antes de definir si se aplicará un SOS, POS, MOS, inhibición, “override”, “forcé” o “defeat”, tengamos claras sus diferentes aplicaciones.

La primera aclaratoria es que todos estos términos entran en la definición de bypass; sin embargo, los podemos clasificar por el efecto que tienen en la función (bypass de la señal de entrada o la salida) y por los diferentes modos de operación asociados al proceso donde se utiliza (operación normal, puesta en marcha, mantenimiento, entre otros), como vemos en la siguiente figura:

Los SOS, POS y MOS son facilidades utilizadas para un propósito específico en el proceso, dentro de sus diferentes modos de operación.

Los SOS (Start up Override Switch) son necesarios si el proceso debe pasar por el punto de ajuste de disparo de la SIF, al momento del arranque o inicio de una secuencia de operación. Al tener esta facilidad, se coloca fuera de servicio la SIF para permitir el inicio del proceso; por ejemplo, cuando se inicia el llenado de un recipiente y se tiene una SIF que protege por bajo nivel en ese recipiente.

Los POS (Process Override Switch) son aplicados cuando el proceso está «fuera de servicio» o «inactivo»; es decir, cuando está en un modo de operación en el que no existe peligro potencial. Los POS, generalmente, se instalan para permitir actividades de mantenimiento, por ejemplo: pruebas funcionales del SIS o para proporcionar aislamiento de instrumentos durante las pruebas hidrostáticas de equipos de proceso.

Los MOS (Maintenance Override Switch) están asociados al equipamiento de la SIF para su mantenimiento o reparación. El MOS se aplica cuando el equipo está en un modo de operación o en una condición donde existe peligro potencial. Estos normalmente actúan sobre el elemento final, impidiendo que se produzca el disparo de la SIF, sin eliminar las alarmas del sistema.

En caso del “inhibit” y “override”, que a su vez pueden ser aplicados por medio de “force” o “defeat”, son facilidades de bypass que dependen del propósito asociado a su configuración en la función.

Inhibit (Inhibición) es un término definido por la norma ANSI / ISA-84.01-1996 como “no permitir que ocurra una acción”. Este término, por lo general, está asociado a un bypass que evita o deshabilita la función del elemento sensor de un sistema, ya sea a través de una función por software o hardware. Este tipo de bypass no necesariamente elimina la función de medición, es decir, puede permitir el anuncio de alarmas asociados, así como el control manual de la función.

Override (anulación) es referido al término NULO en la RAE, algunas de sus definiciones son: 1. tr. Suspender algo previamente anunciado o proyectado; 2. tr. Incapacitar, desautorizar a alguien. Este término es comúnmente vinculado a un bypass que deshabilita la señal de salida o la establece en un estado predefinido, ya sea a través de una función por software o hardware.

Una manera simple de representar estos tipos de configuración de bypass se muestra en la figura:

Por último, estas facilidades pueden ser implementadas a través de “force” o “defeat”.

Cuando se habla de “force”, se hace referencia a la manipulación del valor o el estado de una variable con el fin de retener un cierto estado de la función y evitar que esta actúe en el momento que sea requerido. Generalmente, en un SIS esto se hace desde la herramienta de programación del controlador y sobre el programa de aplicación. Sin embargo, realizar el “force” sobre el programa de aplicación resulta en una práctica bastante peligrosa puesto que no, necesariamente, hay facilidades para enterarse que existen este tipo de bypass instalados, a menos que se tenga acceso al controlador a través de las herramientas de programación.

El término “defeat” normalmente es referido a la anulación de la capacidad de operación de una SIF, aunque es menos común, se asocia a una facilidad física (controlada o no) y no tanto a una facilidad lógica como el “force”. En el plano físico, puede ser desde un interruptor de bypass hasta un cable no autorizado (puente), que coloca fuera de servicio la entrada o salida de la SIF.

Para finalizar, debemos tener en cuenta que un bypass, en cualquiera de sus configuraciones, representa un punto de vulnerabilidad para el proceso, ya que una SIF en estado de bypass puede significar que ya no es capaz de actuar; por esto, deben ser diseñados cuidadosamente para minimizar el riesgo y mantener la confiabilidad del sistema. Solo teniendo una visión clara de lo que se quiere, es que podemos tener los resultados esperados; por lo que, al definir un bypass asociado a una SIF, debemos considerar su propósito en el proceso (definir si será utilizado para el mantenimiento, la puesta en marcha u otra condición específica del proceso) y el tipo de configuración (si es necesario desviar la entrada o la salida o si se consideran los parámetros del proceso, alarmas, etc.).

En el siguiente blog hablaremos de los requerimientos descritos en la IEC-61511: 2016 para la gestión adecuada de los bypass asociados al SIS, así podremos tener una visión más amplia de cómo aplicarlos en el marco de la seguridad funcional.

Bypass, muchos nombres ¿mismo fin? Leer más »

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 »

¿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 »

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 »

Cumpliendo con IEC 61511-1: ¿Por dónde empiezo?

Gestión de la Seguridad Funcional / /

En la industria de procesos, la experiencia ha demostrado que cuando la seguridad no es gestionada correctamente, los sistemas de protección no son capaces de proveer la reducción de riesgos que de ellos se espera, pudiendo llegar hasta un accidente.

Los Sistemas Instrumentados de Seguridad (SIS) son uno de los principales sistemas utilizados en materia de seguridad, y para que un SIS pueda ofrecer seguridad deben tomarse en cuenta todos los factores que puedan afectarlo. Deben ser controladas o evitadas todas las fallas aleatorias (asociadas a la degradación del hardware) y sistemáticas (normalmente asociadas con el software y el diseño).

En los últimos años, a la par de la evolución de la normativa de seguridad funcional para la industria de los procesos IEC 61511, muchas organizaciones han dado muestras de su compromiso en materia de seguridad al adoptar esta norma (considerada como mejor práctica), pero ¿es posible asegurar que el riesgo se mantiene en los niveles determinados como tolerables? o ¿realmente cumplimos con lo exigido por la norma?

El primer paso para demostrar cumplimiento con IEC 61511 es familiarizarnos con la norma, sus requisitos y el ciclo de vida de seguridad. Recordemos que la norma define desde la concepción hasta el desmantelamiento del SIS (a través del ciclo de vida) y nos muestra una forma de trabajo para evitar los errores sistemáticos.

Al conocer la forma de trabajo que debemos seguir, podremos evaluarnos, identificar las actividades que estamos haciendo bien, las que debemos mejorar y las que no son realizadas en forma apropiada. Desde la asignación de responsabilidades, la capacitación del personal, los procedimientos utilizados, el cierre de recomendaciones, entre muchas otras tareas.

Para esto podemos escoger la herramienta que consideremos adecuada; una opción es realizar listas de chequeo que nos permitan revisar punto a punto cada requisito. La meta es conocer la brecha que existe entre la forma que diseñamos, implementamos, operamos y mantenemos los SIS y lo exigido por la norma. Podemos realizar revisiones documentales, entrevistas al personal, visualización de actividades o cualquier otra actividad que encontremos de utilidad; recordando que, al trabajar con normas basadas en desempeño, el usuario es libre de desarrollar sus propias soluciones.

Algunas personas suelen pensar que al comprar un dispositivo certificado están cumpliendo con esta norma (y muchas veces eso nos ofrecen algunos suplidores) cuando realmente no es así, la norma nos pide mucho más que eso (de hecho, no pide equipos certificados). Porque no importa si el SIS fue diseñado bajo el enfoque de esta normativa o no, en cualquiera de los casos se debe demostrar que está siendo operado, mantenido inspeccionado y probado de forma segura. Así lo exige la normativa. Y al mantener el sistema en condiciones tan buenas como las de diseño, no sólo se está adoptando una buena práctica, sino se está extendiendo la vida útil del sistema.

Nuestra meta debe ser asegurarnos que todos los involucrados sepan lo que se espera de ellos, que dispongan de suficiente información para realizar cada trabajo, así como herramientas, recursos y competencias adecuadas. Además, que exista suficiente trazabilidad para demostrar que todos los requisitos de la norma se cumplen realmente.

No debemos esperar que ocurra un accidente o un ente regulador nos pregunte bajo que lineamientos manejamos nuestros sistemas de seguridad, debemos dar ese primer paso en materia de seguridad para trazar el camino que queremos recorrer.

Cumpliendo con IEC 61511-1: ¿Por dónde empiezo? Leer más »

Trabajando en Seguridad Funcional: La importancia de gestionar las Capas de Protección Independientes

Gestión de la Seguridad Funcional / /

Los Análisis de Capas de Protección (LOPA: Layer Of Protection Analysis) se han convertido en una de las herramientas más utilizadas en la industria de procesos para identificar, analizar y evaluar las funciones de seguridad necesarias para alcanzar los criterios de riesgo de una instalación.

Un LOPA nos permite: (a) identificar las funciones de seguridad requeridas, (b) verificar si existen suficientes capas de protección acreditables para evitar o mitigar un posible evento peligroso (en términos de independencia, integridad, efectividad, especificidad y auditabilidad), (c) determinar la brecha de riesgo remanente, una vez contabilizadas todas las capas de protección acreditadas y (d) determinar si es necesario colocar una nueva capa de protección, y sí la misma resulta en una Función Instrumentada de Seguridad (SIF), estimar su SIL asociado.

Al trabajar en el marco de la norma IEC 61511 podemos identificar los requisitos funcionales y de integridad para que las SIF logren la reducción de riesgo requerida, en conjunto las capas de protección acreditables como IPL (IPL: Independent Protection Layer).

El desempeño o SIL (Safety Integrity Level) que debe alcanzar una SIF, está directamente relacionado al buen funcionamiento de todas las IPL consideradas en cada escenario. Si las IPL nos son validadas, probadas y mantenidas apropiadamente, el riesgo estimado puede incrementarse y los accidentes pudieran presentarse de forma más frecuente de lo que fue previsto durante el análisis.

Situaciones comunes como cambios en el diseño, modificación del punto de ajuste de una alarma, eliminación de algún dispositivo, o la falta de mantenimiento pueden afectar la integridad de una IPL, creando una situación potencial de riesgo no cubierto (ni por el SIS ni por la capa que ha sido eventualmente degradada), como podemos apreciar en las siguientes figuras.

 

Figura 1                                                                         Figura2

Identificar una IPL durante las sesiones de trabajo del LOPA es de suma importancia, el grupo de análisis utiliza la información relacionada al proceso para identificar las capas de protección disponibles (P&ID, Filosofías de Control, Manuales, etc.), pero no tiene el tiempo o los recursos para asegurar que cada IPL considerada cumplirá con los requisitos que la acreditan como tal.

A pesar de que el equipo que participa en un LOPA puede identificar las IPL que apliquen a cada escenario, dentro de sus responsabilidades no está el velar por su correcta implementación. Si no existen medios que permitan validar su funcionamiento es muy fácil exponer al personal y la instalación a un riesgo no considerado.

La norma IEC 61511 no regula el diseño, mantenimiento y operación de las IPL (no SIF), pero en ella se establecen evaluaciones (o assessment) que deben ser realizadas durante el diseño, antes de la puesta en marcha y durante la operación en las que debemos considerarlas. El buen funcionamiento de las IPL depende de la forma en que cada organización maneje su sistema de integridad mecánica (por ejemplo, como parte la Gestión de Seguridad de Procesos PSM).

Como vemos, las IPL (en conjunto con las SIF) nos ayudan a mantener los niveles de riesgo dentro de valores tolerables al evitar (o mitigar) la propagación de un evento peligroso. Pero, debemos recordar que la correcta implementación de una IPL inicia desde el momento que documentamos las sesiones de un LOPA, y solo se alcanza cuando todo el personal encargado de su funcionamiento o involucrado en su mantenimiento se hace consciente que, además del proceso de selección, es importante gestionarlas, validarlas, probarlas, auditarlas y documentarlas apropiadamente a lo largo de su vida útil.

Trabajando en Seguridad Funcional: La importancia de gestionar las Capas de Protección Independientes Leer más »

Trabajando en Seguridad Funcional: La gestión como herramienta para evitar las fallas sistemáticas

Gestión de la Seguridad Funcional / /

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

Para diseñar, mantener y operar, de forma adecuada, un Sistema Instrumentado de Seguridad (SIS), que es hoy día uno de los principales sistemas automatizados utilizados en la seguridad, se deben tomar en cuenta todas las causas que pudieran afectar su funcionamiento. Una
adecuada gestión de la seguridad funcional que permita controlar las fallas aleatorias (asociadas a la degradación del hardware) y evitar las fallas sistemáticas (usualmente asociadas al factor humano) es esencial. Esto implica el uso de materiales de primera, procesos de diseño y fabricación de alta calidad, es decir, hacer un diseño que sea lo suficientemente robusto para soportar cualquier fuente de estrés y generar nuevas formas de trabajo que permitan realizar las tareas de diseño, fabricación, instalación, mantenimiento y operación en forma sistemática.

La seguridad funcional se ha beneficiado de los avances y esfuerzos realizados por fabricantes en tratar de generar productos certificados que den cierto nivel de garantía sobre el grado de integridad que sus productos pueden ofrecer y de la comprensión de los usuarios finales sobre la importancia de definir un nivel de integridad y diseñar en función a éste. Pero, hacer el trabajo relacionado con la seguridad funcional con un enfoque sistemático y fomentar una cultura de seguridad funcional que nos ayude a evitar las fallas sistemáticas es sin duda nuestro siguiente desafío. Para tener una idea del desafío que debemos enfrentar, podemos citar a Angel Casal en su publicación “SIS Pitfalls, Major Accidents and Lessons Learned”, quien nos indica que desde 1987 al 2012 el 90% de los accidentes mayores ocurridos en la industria de procesos son debidos a fallas sistemáticas.

La normativa internacional de seguridad funcional IEC 61508, su normativa específica para la industria de los procesos IEC 61511 y su equivalente ISA 84.00.01 nos dan una guía y unos pasos (en un orden especifico) que nos permite asegurar que estos sistemas están siendo manejados bajo un enfoque sistemático y holístico en cuanto a su diseño, operación y mantenimiento y que el riesgo se mantiene en los niveles determinados como tolerables.

Ahora bien, si sabemos que adoptar estos estándares nos ayuda a combatir las fallas que pueden presentar estos sistemas, ¿Por qué no implementarlos si son considerados como mejores prácticas en muchas partes del mundo?

Cuando hablamos de gestión de la seguridad funcional muchos de los elementos a considerar son muy parecidos a los utilizados en gestión de proyectos. Una buena gestión de la seguridad funcional debe definir las actividades que serán desarrolladas (es decir cada paso del Ciclo de Vida de Seguridad), debe indicar cuando serán desarrolladas estas actividades y que herramientas serán utilizadas. Además, debe definir los recursos y las personas que serán responsables. En general, debemos considerar:

  • Una planificación de las actividades que serán realizadas en cada fase del Ciclo de Vida de Seguridad, con la descripción de los requisitos de cada una, incluyendo las actividades de verificación y evaluación (assessment). Esto es, esencialmente, el plan de ejecución que se aplicará al proyecto, en función del alcance que debamos cubrir.
  • La definición de la organización donde se designen los responsables y las personas que formarán parte del equipo de trabajo. Se debe garantizar que las personas sean competentes para realizar cada una de las tareas que le fueron asignadas en cada fase y se debe asegurar que cada uno de ellos tenga las competencias requeridas según el rol que deban desempeñar.
  • La definición de las guías y procedimientos a utilizar, es decir, debemos definir cómo deben ser desarrolladas cada una de las actividades y que herramientas serán utilizadas.
  • La documentación que necesitamos para realizar un trabajo, la información que debe ser generada y la forma en la que debe ser manejada para que sea utilizada apropiadamente a lo largo de la vida útil de los sistemas.
  • Las evaluaciones periódicas que nos permitan comprobar que los riesgos están siendo mantenidos en niveles tolerables y que los procedimientos de trabajo están siendo utilizados en forma apropiada por personal capacitado.

La siguiente figura nos muestra de forma gráfica todos los elementos que hemos mencionado hasta ahora,

Figura
1. Gestión de la Seguridad Funcional

Como vemos, adoptar una buena práctica recomendada para sistemas automatizados (o instrumentados) no es algo que se aleja de nuestra realidad al gestionar un proyecto, solo requiere de un profundo compromiso con la mejora continua. Implementar este tipo de normativas nos permite identificar mejoras en materia de seguridad que se adapten a nuestra forma de trabajo, puesto que, al estar basadas en desempeño, el usuario es libre de desarrollar diseños y soluciones que demuestren cumplimiento dentro del esquema de trabajo establecido por la normativa.

Así que, luego de manejar toda esta información ¿por qué no darle la importancia que se merece una buena gestión de seguridad funcional, si sabemos que al no implementarla los sistemas se degradan y aumentan los riesgos?

Trabajando en Seguridad Funcional: La gestión como herramienta para evitar las fallas sistemáticas Leer más »

Aseguramiento de Calidad Cuando Trabajamos en Seguridad Funcional

Gestión de la Seguridad Funcional / /

La revisión de la cláusula 8 de la norma ISO 9001: 2015. Sistemas de Gestión de la Calidad – Requisitos está enfocada en la mejora del control de los procesos productivos de cada organización. Se hace énfasis en la cadena de suministro, con el fin de que los productos que son generados de forma externa estén conformes a los requisitos especificados. Para esto, se deben definir los criterios y procesos que serán
utilizados para asegurar la calidad de los productos y servicios que pudieran ser contratados.

En materia de Seguridad Funcional no es diferente, en la Normativa IEC 61511-1: 2016. Functional Safety – Safety Instrumented Systems for The Process Industry Sector también se establecen lineamientos para el aseguramiento de la cadena de suministros, tanto de productos como de servicios, a fin de garantizar que ambos estén conformes a la normativa y así asegurar que la Seguridad Funcional (alcanzada por los Sistemas Instrumentados de Seguridad) dentro de la Organización Cliente (o Contratante) sea capaz de proveer el grado de reducción de riesgo (o la seguridad) requerido en sus instalaciones y demostrar conformidad ante los entes reguladores y las empresas aseguradoras.

La Normativa IEC 61511-1: 2016 en su clausula 5.2.5 Implementing and Monitoring (5.2.5.2) establece: “Todo proveedor que suministre productos o servicios a una organización que tenga la responsabilidad general de una o más fases del ciclo de vida de seguridad del SIS deberá entregar los productos o servicios especificados por esa organización y disponer de un sistema de gestión de la calidad. Se establecerán procedimientos para demostrar la idoneidad del sistema de gestión de la calidad.

Si un proveedor formula declaraciones de cumplimiento de seguridad funcional para un producto o servicio que la organización utiliza para demostrar el cumplimiento de los requisitos de esta parte de la IEC 61511, el proveedor deberá tener un sistema de gestión de la seguridad funcional. Deben establecerse procedimientos para demostrar la idoneidad del sistema de gestión de la seguridad funcional.

El sistema de gestión de la seguridad funcional deberá cumplir los requisitos de la norma de seguridad básica IEC 61508-1: 2010 Cláusula 6, o los requisitos de gestión de seguridad funcional de la norma derivada de IEC 61508, a los que se hacen declaraciones de cumplimiento de seguridad funcional.”

Por esta razón, cuando hablamos de Seguridad Funcional, es un requisito mandatorio que los proveedores de productos y servicios, de una Organización Cliente (o Contratante) que posea un Sistema Gestión de Seguridad Funcional conforme a la Normativa IEC 61511-1: 2016, tengan implementado un Sistema Gestión de Seguridad Funcional que garantice que el resultado de ese servicio esté conforme a los requisitos de la normativa en cada aspecto. En caso de ser un proveedor de productos, el Sistema Gestión de Seguridad Funcional deberá estar conforme a la norma IEC 61508-1: 2010, y en caso de ser un proveedor de servicios del Ciclo de Vida de Seguridad deberá estar de acuerdo con IEC 61511-1: 2016.

 

Para verlo en forma más práctica, una organización que posea personal competente, por ejemplo, un líder de HAZOP, no garantiza que el estudio se encuentre conforme a la Normativa IEC 61511-1: 2016 debido a que la gestión de las competencias del personal es solo uno de los componentes que deben ser considerados al implementar un Sistema Gestión de Seguridad Funcional. Existen muchos otros factores a considerar como son la planificación de la Seguridad Funcional, la asignación de los recursos y procedimientos que serán utilizados, la verificación y evaluación (assessment) de la fase del ciclo de vida de seguridad desarrollada, la gestión de la documentación, entre otros.

Ahora bien, ¿Cuáles son los beneficios para una Organización Cliente si el proveedor de productos y servicios posee un Sistema Gestión de Seguridad Funcional certificado?

  • Reducción de los costos asociados a las actividades de gestión en la cadena de suministro. Los resultados de los productos y servicios contratados ya están conformes a la normativa IEC 61511-1: 2016, por lo que se requiere menos esfuerzo ingenieril para revisión por parte del personal de la Organización Cliente y se disminuyen los costos asociados a la contratación de personal que no es esencial o primordial para el negocio.
  • Demostrar cumplimiento con la Normativa IEC 61511-1: 2016 y otras relacionadas con la seguridad. Los resultados de los productos y servicios contratados pueden ser usados como aval para auditoria de seguridad, bien sea de la autoridad con jurisdicción o ante las aseguradoras.
  • Evaluación de terceros independientes. No hay necesidad de realizar una auditoria externa que valide los resultados obtenidos, la evaluación fue realizada por un tercero acreditado para tal fin.
  • Personal Competente. El Sistema Gestión de Seguridad Funcional asegura que el personal es competente para realizar cada una de las actividades del Ciclo de Vida de Seguridad de las que son responsables.
  • Calidad. Los productos y servicios están conformes a la normativa que rige lo relacionado con la Seguridad Funcional.

Por eso, al momento de contratar un producto o servicio relacionado con la Seguridad Funcional, debemos preguntarnos:

¿Su proveedor de Productos y Servicios esta Certificado de conformidad con la Normativa IEC 61511-1: 2016?

¿Su proveedor de Productos y Servicios posee un Sistema de Gestión de Seguridad Funcional?

¿Los procedimientos de su proveedor de Productos y Servicios están Certificados por un Tercero Acreditado y Reconocido mundialmente?

O considerar, ¿Por que si al comprar un elemento de hardware del SIS se exige un certificado de fabricación conforme con la norma IEC 61508: 2010, no se hace lo mismo con quienes proveen servicios relacionados con el Ciclo de Vida de Seguridad como son la Identificación de Peligros y Riesgos (usando la técnica HAZOP) o la Asignación del SIL (usando la técnica LOPA)?

Aseguramiento de Calidad Cuando Trabajamos en Seguridad Funcional Leer más »