Romel Rodríguez

IEC 61511: 10 cosas que debes saber de la norma

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 »

Claves para el éxito de estudios de riesgos en forma remota

computador durante estudios de riesgo

Esta entrada trata sobre la adaptación, sobre cómo realizar estudios de riesgos (que por su naturaleza necesitan de la participación de grupos multidisciplinarios) en tiempos de restricciones de movilidad, como los que estamos viviendo.

En este caso, se requiere de una mayor preparación que en un estudio convencional y se debe definir el alcance claramente, asegurando que se entiende el proceso y la tecnología en una reunión previa.

El equipo de trabajo

Al formar el equipo de trabajo, debemos enfocarnos en maximizar los resultados. Se recomienda que, en estos casos, el Líder del Estudio, además de tener experiencia en la metodología y la tecnología de comunicación, sea capaz de administrar el tiempo y mantener al grupo enfocado, activo y participativo, poniendo atención sobre lo que se quiere discutir.

Es muy importante minimizar las distracciones y discusiones secundarias.

El secretario es esencial para sesiones remotas (un par de oídos extras), debe conocer la metodología, ser suficientemente organizado y atento a los detalles para sintetizar la información. Un buen secretario hace la diferencia en cualquier estudio de riesgo.

El grupo de trabajo debe mantenerse tan reducido como sea posible, con los representantes mínimos necesarios y la participación de especialistas y representantes de equipos paquetes en forma puntual. Las herramientas de comunicación hoy día no representan mayor dificultad; por ejemplo, en la actualidad hablamos de un tráfico por día de 300 millones de participantes en ZOOM y de unos 200 Millones en Microsoft Teams, sin contar otras opciones como Webex o Skype, solo por nombrar las más populares. La opción que decidamos utilizar debe permitir comunicación instantánea de audio y video, múltiples usuarios, registro de asistencia, opciones para compartir pantallas y archivos, grabación de las sesiones y una conexión segura. La recomendación principal es probar, probar, probar.

Preparación del estudio

Con relación a la preparación del estudio, se recomienda definir los nodos y estructurar el estudio con la cantidad de detalle que sea posible (escenarios, desviaciones y causas probables), asegurando la disponibilidad y el orden de toda la información.

Debemos enfocarnos en la eficiencia de las sesiones de trabajo. Una buena práctica es realizar una capacitación inicial sobre la metodología y el alcance del estudio; de esa forma, es posible ajustar las expectativas en forma previa. Si la planificación lo permite, implementar sesiones de 4 horas diarias y de 3 o 4 días por semana, considerando el rendimiento y los husos horarios de los involucrados.

Podemos pensar que al disminuir la cantidad de tiempo en las sesiones mermaría la eficiencia, pero el uso de grupos reducidos hace que el rendimiento sea muy bueno; pueden ser jornadas cortas pero intensas – aún más que las convencionales.

Claves de éxito

Recordemos que ésta no es una reunión cualquiera, es una reunión de revisión exhaustiva, por lo que, se debe prestar atención a los siguientes aspectos: 

  • Establezca las reglas de juego – por ejemplo, el uso de las funciones mute y levantar la mano para asegurar que hable uno a la vez.
  • Administre el tiempo – las intervenciones deben ajustarse al propósito y alcance del estudio.
  • Controle su ambiente circundante – desde su comodidad (tener todo a la mano) hasta las fuentes de ruido y distracción.
  • Identifique al personal clave – por su nombre (las aplicaciones identifican la conexión individual) y apóyese en él para enfocar la discusión sobre el punto que éste maneja.
  • Organice la información que se va a compartir y verifique el tamaño de la fuente utilizada en el software.
  • Asegúrese de que existe realimentación de las comunicaciones y que cada mensaje haya sido recibido efectivamente antes de avanzar – recuerde que ya no existe el feedback físico.
  • Evalúe la efectividad y haga ajustes continuamente -poniendo atención a los detalles y realimentándose de lo que sucede (detectar cuando se puede avanzar sobre un tema y cuáles requieren mayor profundidad de discusión).

No hay duda de que esta forma de trabajo, que muchos recién experimentan, ha llegado para quedarse; por lo que, debemos encontrar maneras efectivas que nos permitan seguir haciendo los estudios de riesgos a pesar de las circunstancias actuales.

No existen limitaciones tecnológicas para la realización de estudios de riesgos en forma remota, solo nos queda entender que las condiciones demandan nuevas formas de trabajo y detenernos no es una opción.

Mantenerse al día implica adaptarse y empezar a trabajar de una forma diferente.

Romel Rodríguez
CSF Consultoría en Seguridad Funcional
rodriguezrx@grupocsf.com

Claves para el éxito de estudios de riesgos en forma remota Leer más »

¿Contratas Servicios de Ingeniería relacionados con la Seguridad Funcional?

Imagínese que reservó en un restaurante que tiene muy buena publicidad y después de recibir el servicio no queda satisfecho. ¡No era lo que estaba esperando!
Luego puede notar que, a pesar de que la comida es buena, es un restaurante italiano donde el chef es especialista en comida mexicana (sin competencias); no hay una persona que asegure (verifique) que cada plato salga de la cocina como fue ordenado (en condiciones adecuadas) y no hay un jefe de mesoneros que asegure (evalúe) un buen servicio al cliente.
Esas cosas son más frecuentes de lo que imaginamos; si no gestionamos adecuadamente lo relacionado a las actividades que realizamos, algo puede salir mal.
En Seguridad Funcional no es muy distinto a la vida real, cada trabajo debe ser gestionado, realizado, verificado, evaluado y (dependiendo del caso) también puede ser auditado. Como explico a continuación, y vemos en la figura 1, llevar a cabo una tarea requiere que estén involucradas (al menos) cuatro figuras o roles:
  • El que debe Gestionar todo lo que se realiza; quien se encargará de asignar las responsabilidades y asegurar que el elaborador, verificador, evaluador y auditor, sean competentes para hacer sus trabajos y, además, los realicen siguiendo una planificación y usando herramientas y procedimientos adecuados.
  • El que debe Hacer una tarea; quien tiene la responsabilidad de cumplir un objetivo (según los requisitos de la norma) y debe ser competente para realizar el trabajo que se le ha asignado.
  • El que debe Verificar; quien es diferente al que ejecuta y se encarga de asegurar que las tareas del elaborador (el que hace) estén en conformidad con todos y cada uno de los requisitos y objetivos de la norma.
  • El que Evalúa; quien decide si la Seguridad Funcional es alcanzada y evalúa si las personas con las competencias requeridas realizaron el trabajo correspondiente, usando las herramientas y procedimientos apropiadas, siguiendo el plan designado.
 
 
Figura 1. Roles de la Seguridad Funcional
Normalmente, todas estas figuras (o roles) podemos verlas en organizaciones que disponen de un Sistema de Gestión de la Seguridad Funcional que cumplen con las disposiciones que exige la norma IEC 61511-1: 2016 (recordemos que la norma en su punto 5.2.5.2, indica que las organizaciones que tengan responsabilidad sobre el SIS deben tener un Sistema de Gestión de Seguridad Funcional y, en el 5.2.2.3, establece que debe existir un Sistema de Gestión de Competencias del personal).
Al contratar solo una persona con experiencia, en lugar de una organización con un Sistema de Gestión de Seguridad Funcional, además incumplir con la norma, nos exponemos a situaciones como:
  • Incumplimiento del Sistema de Gestión de Seguridad Funcional y Calidad de la organización contratante (en caso de que lo posea).
  • Posibles cambios de alcance en la contratación de servicios para cubrir las tareas de gestión, verificación y evaluación.
  • Horas Hombres adicionales cargadas al personal de la organización contratante para cubrir las actividades no realizadas.
  • Incumplimiento de alguna fase del ciclo de vida que impida continuar con las actividades requeridas (siguiente fase del ciclo de vida), generando retrabajo en el proyecto.
  • Diseños inadecuados del SIS, exponiendo las instalaciones a un riesgo innecesario.
A continuación, mostraré cómo podrían traducirse las situaciones que he mencionado en la contratación de servicios de ingeniería relacionados al SIS y los resultados esperados, con la idea de que pueda ubicarse en alguno de estos casos y tomar acciones si es necesario.
Escenario 1. El ideal.
Usuario Final: Usuario con un Sistema de Gestión de Seguridad Funcional implementado, procedimientos consolidados y especificaciones de contratación claras.
Consultor de Ingeniería: Consultor con un Sistema de Gestión implementado y procedimientos consolidados, con especificaciones de contratación claras.
Consultor de Seguridad Funcional: Organización con un Sistema de Gestión de Seguridad Funcional implementado y procedimientos consolidados.
Posible resultado: Productos en especificación y de conformidad con la normativa. Caso óptimo.
Escenario 2. El bueno.
Usuario Final: Usuario con un Sistema de Gestión de Seguridad Funcional implementado, procedimientos consolidados y especificaciones de contratación claras.
Consultor de Ingeniería: Consultor sin un Sistema de Gestión implementado, con especificaciones de contratación claras derivadas del Usuario Final.
Consultor de Seguridad Funcional: Consultor con un Sistema de Gestión de Seguridad Funcional implementado y procedimientos consolidados.
Posible resultado: Productos en especificación y de conformidad con la normativa. El Consultor de Ingeniería deriva en el Consultor de Seguridad Funcional el Plan de Seguridad Funcional. (Nota: Todos los actores deben tener un Plan de Seguridad, esto incluye al Consultor de Ingeniería).
Escenario 3. El común.
Usuario Final: Usuario con un Sistema de Gestión de Seguridad Funcional implementado, procedimientos consolidados y especificaciones de contratación claras.
Consultor de Ingeniería: Consultor sin un Sistema de Gestión implementado, con especificaciones de contratación claras derivadas del Usuario Final.
Consultor de Seguridad Funcional: Consultor experto de seguridad Funcional,
Posible resultado: En este caso existen dos posibles salidas, en las dos el contratante pierde. Inicialmente parece menos costoso, pero a la larga generará más retrabajo y, por ende, más costos, inclusive poniendo en riesgo el desarrollo del proyecto:
a) Productos fuera de especificación y no conformes a la norma ya que, para el desarrollo de los mismos, no existe un Plan de Seguridad del Proyecto, no se gestionaron las competencias, no se establecieron los roles de gerente de seguridad funcional, verificador ni evaluador. Así, los productos no han podido ser verificados para constatar si están conformes con los requisitos de la norma.
b) Productos en especificación y de conformidad con la normativa. Esto sucederá solo sí el Consultor de Ingeniería asume la responsabilidad de las tareas de gestión, verificación y evaluación, así como el Plan de Seguridad Funcional y de gestión de competencias.
Escenario 4. El complicado.
Usuario Final: Usuario sin un Sistema de Gestión de Seguridad Funcional implementado, sin procedimientos consolidados y sin especificaciones de contratación claras.
Consultor de Ingeniería: Consultor sin un Sistema de Gestión implementado y sin especificaciones de contratación claras.
Consultor de Seguridad Funcional: Organización con un Sistema de Gestión de Seguridad Funcional implementado y procedimientos consolidados.
Posible resultado: El Usuario Final solicitará un alcance por defecto o por exceso al no tener clara la forma de trabajo que la normativa impone, creando una enorme desventaja entre los contratados. La única forma de generar un producto de conformidad con la norma (y económicamente viable) es hacer un esfuerzo inicial de aclarar el alcance con todos los participantes.
Escenario 5. El feo.
Usuario Final: Usuario sin un Sistema de Gestión de Seguridad Funcional implementado, sin procedimientos consolidados y sin especificaciones de contratación claras.
Consultor de Ingeniería: Consultor sin Sistema de Gestión implementado y sin procedimientos consolidados ni especificaciones de contratación claras.
Consultor de Seguridad Funcional: Consultor de seguridad sin conocimientos de seguridad Funcional.
Posible resultado: Receta perfecta para el desastre.
En conclusión, cuando un Usuario Final o un Consultor de Ingeniería contrata un servicio asociado al Ciclo de Vida de Seguridad (HAZOP, LOPA, SRS, Verificación del SIL, etc.) y lo hace a una organización con un Sistema de Gestión de la Seguridad Funcional, no solo cumple con la norma, sino que, tomando todas las ventajas de esa organización, reduce sus esfuerzos en conseguir los productos requeridos en el tiempo estimado, con la calidad requerida y de conformidad de la norma.
Ejemplo Práctico: Contratación de HAZOP
1- Usuario Final: Petroleum & Gas Producers
Sistema de Gestión de la Seguridad Funcional: Implementado a nivel corporativo.
Procedimiento de Hazop: Según la IEC 61882 y los requerimientos de la cláusula 8 de la IEC 61511. 
Especificaciones de Contratación: Generales del proyecto de Ingeniería y Construcción.
2- Consultor de Ingeniería: Engineers & Constructors INC:
Sistema de Gestión: Sistema de Gestión de Calidad ISO 9000.
Procedimiento de Hazop: Usará el indicado por Petroleum & Gas Producers.
Especificaciones de Contratación: Estándar de contratación corporativo que incluye el procedimiento de HAZOP Petroleum & Gas Producers entre sus anexos.
3- Consultor de Ingeniería:
 a) Experto Pedro Pérez.
Sistema de Gestión de la Seguridad Funcional: No Posee. No habrá quien gestione (planifique, asigne: responsabilidades, personal competente, herramientas y procedimientos), no hay quien verifique ni quien evalué el producto. Solo existe la figura de quien
lidere el estudio, es decir el Elaborador.
Procedimiento de Hazop: Cada Pedro Perez experto tendrá un procedimiento producto de sus experiencias y posiblemente no concuerde con lo requerido en la normativa y, por ende, con el procedimiento de HAZOP Petroleum & Gas Producers, creando inconsistencias de resultados en cada contratación. Además, generando riesgo de no cumplimiento con la fase del ciclo de vida, diseños inadecuados del SIS, retrabajo para el contratante y posibles cambios de alcance.
b)  Consultor de Seguridad A.
Sistema de Gestión de la Seguridad Funcional: No Posee. No se garantiza que exista una panificación, una asignación de; responsabilidades, personal competente, herramientas y procedimientos. Tampoco se garantiza la verificación del Hazop respecto a los requisitos de la norma ni la evaluación de la seguridad funcional como parte del ciclo de vida de seguridad. Solo se asegura la existencia del equipo Elaborador.
Procedimiento de Hazop: Como no existe un Sistema de Gestión no existe garantía de que el procedimiento concuerde con lo requerido
en la normativa y, por ende, con el procedimiento de HAZOP Petroleum & Gas Producers, creando inconsistencias de resultados en cada contratación. Además, generando riesgo de no cumplimiento con la fase del ciclo de vida, diseños inadecuados del SIS, retrabajo para el contratante y posibles cambios de alcance.
c)  Consultor de Seguridad B.
Sistema de Gestión de la Seguridad Funcional: Implementado y con procedimientos consolidados.
Procedimiento de Hazop: La existencia del Sistema de Gestión garantizará que procedimiento de HAZOP concuerde con lo requerido en la normativa y, por ende, con el procedimiento de HAZOP Petroleum & Gas Producers, creando consistencia en cada contratación y con productos de conformidad con la normativa.
Romel Rodríguez
CSF Consultoría en Seguridad Funcional
rodriguezrx@grupocsf.com

¿Contratas Servicios de Ingeniería relacionados con la Seguridad Funcional? Leer más »

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

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

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

Trabajando en Seguridad Funcional: ¿Qué significa verificar?

 

En esta entrada estaré haciendo una colaboración en el Blog de Eliana Berroteran “Trabajando en Seguridad Funcional” para discutir sobre un punto que realmente nos parece de suma importancia cuando hablamos de trabajar el día a día de la seguridad funcional.

En el contexto de la seguridad funcional, verificar significa que debemos “demostrar mediante revisión, análisis y/o prueba que los productos requeridos satisfacen los requisitos definidos para las fases que han sido planificadas.”

Esto es, que cada tarea realizada, dentro del marco del ciclo de vida de los Sistemas Instrumentados de Seguridad, debe estar sujeta a un control de calidad respecto a los requisitos de la normativa, en nuestro caso la IEC 61511:2016 o ISA:61511:2018.

Muchas veces, las personas y las organizaciones pierden de vista este pilar básico de la gestión de la seguridad funcional; imagínense ¿cómo saber si se está cumpliendo con los requisitos de la norma si no contrastamos el trabajo con lo que ella exige?

La normativa es clara al hacer énfasis en 2 cosas: a) que la organización posea un Sistema de Gestión de la Seguridad Funcional que asegure que el trabajo se realiza de forma adecuada y según la normativa; y, b) que el personal asignado sea competente.

Colocar personas competentes a realizar el trabajo muchas veces apenas alcanza para cumplir con los principales aspectos técnicos del trabajo. El éxito sólo puede ser alcanzado a través de un Sistema de Gestión de Seguridad Funcional que, primero, vele porque el personal
asignado para realizar el trabajo sea competente y, segundo, que el trabajo esté realizado de conformidad con la norma, asegurando la ejecución de tareas claves como la verificación.

Muchas veces cuando consultamos a nuestros clientes sobre los aspectos relacionados a la verificación, nos podemos dar cuenta que no existe una cultura arraigada de la realización de estas tareas; las mismas no se planifican porque ni siquiera están en las listas de tareas por hacer, contratar o supervisar, simplemente no existen. Esto se debe, por lo general, a que no poseen un Sistema de Gestión de Seguridad Funcional y, por ende, no han hecho de la verificación una parte natural de su cultura de trabajo, a pesar de ser un requisito primordial para el aseguramiento de la seguridad funcional.

A veces sólo preguntamos: ¿Cómo se pudo avanzar en una fase del ciclo de vida de seguridad si la anterior no ha sido verificada? Y la respuesta es una encogida de hombros. Esto deja la brecha que necesitan las fallas sistemáticas para colarse y hacer que el SIS falle, justo lo que la normativa, a través del ciclo de vida de seguridad, como forma de trabajo, está tratando de evitar.

Otras veces, si preguntamos por la verificación, recibimos como respuesta: “ah claro el estudio de verificación del SIL se realizó con éxito”, haciendo referencia a la cuantificación de la falla aleatoria del hardware del SIS, que si bien es importante y es uno de los ítems que se debe cumplir en la fase de diseño, pues no es la verificación a la cual estamos haciendo referencia.

En la práctica, realizar una verificación significa que, al planificar una tarea específica dentro del ciclo de vida de la seguridad funcional, (por ejemplo, la realización de un Análisis de Peligros y Riesgos (PHA), digamos un Hazop), pues todos -sí, todos sin excepción- los requisitos de la normativa para la realización de la cláusula (Process H&RA) deben ser cumplidos. Debe existir una tarea separada que se encargue de velar por revisión, análisis y/o prueba que efectivamente el trabajo fue realizado en forma correcta, respecto a los requisitos de esa cláusula.

Invitamos a nuestros lectores a hacerse estas preguntas: ¿nuestro sistema de gestión de la seguridad funcional está funcionando adecuadamente?, ¿estamos contemplando las verificaciones en nuestros proyectos?, ¿se están realizando las verificaciones en los proyectos
que estamos manejando?

 

PONGA A PRUEBA SUS CONOCIMEINTOS.

Preguntas de esta entrada:

Trabajando en Seguridad Funcional: ¿Qué significa verificar? Leer más »

Seguridad Funcional, una cuestión de tiempo

La palabra Tiempo está íntimamente ligada a la Seguridad Funcional que una Función Instrumentada de Seguridad (SIF) provee. En esta entrada, y sin ánimos de hacer alarde de complejas fórmulas matemáticas, expondré la relación de esta palabra con los diferentes aspectos que rodean la Seguridad Funcional.
Lo primero que debemos entender es la efectividad. Si queremos que una SIF haga su trabajo en forma efectiva, debemos asegurar que la misma sea capaz de ejecutar su tarea antes de que el escenario peligroso se consolide (transformándose en un accidente). Para esto, desde el
inicio del diseño de la función, debemos tener en cuenta el Tiempo de Seguridad del Proceso (PST: Process Safety Time). Si no somos capaces de asegurar que la función lleve al proceso al estado seguro y lo mantenga allí en por lo menos la mitad del PST, no es posible ejecutar la tarea de la seguridad por ese medio y será mejor buscar una opción distinta. Entonces,
Calcular el Tiempo de Actuación de la función de seguridad es de suma importancia. En la figura 1 se muestra la relación entre el Tiempo de Seguridad del Proceso y el Tiempo de Actuación de la SIF. Nota para el lector ¿Cuántas veces se ha detenido a calcular la velocidad de cierre de la válvula de bloqueo respecto a las necesidades de seguridad del proceso?
 
Figura 1. Tiempo de Seguridad del Proceso y Tiempo de Actuación de la SIF.
 
Hablemos ahora de la forma en que la SIF provee seguridad. Una vez que la SIF haya sido diseñada e instalada correctamente, es necesario que esté disponible para hacer su trabajo. Ahora bien, ¿qué cosas pueden pasar para que la función no esté disponible? Veamos:
 
1-    Que la SIF esté en By-pass. Dependiendo del nivel de redundancia (y si no se toman las previsiones establecidas en las normativas durante ese tiempo), la colocación en By-pass de la SIF pudiera dejar a la instalación sin la reducción de riesgo necesaria. Lo cierto es que la escogencia del Tiempo del By-pass (TD: Test Duration) durante los cálculos de verificación del SIL de la SIF deben ser estimados según las políticas de la instalación y reflejar las practicas reales de la misma (¿cuántas veces al año y por cuánto tiempo estima que la SIF estará en By-pass?, ¿por qué razones?). Aunque el By-pass descrito acá es principalmente para efectos de mantenimiento, no debe descartarse que el By-pass puede ser operacional (por ejemplo, necesario para el arranque de una instalación) en cuyo caso también debe ser tomado en cuenta. La figura 2 muestra el efecto del Tiempo del By-pass (TD) sobre la disponibilidad de la SIF. Nota para el lector ¿Cuántas veces en una SIF con un sensor sin redundancia que ha sido colocado en By-pass, tomó previsiones para que la seguridad que brindaba esa SIF la provea otro medio (por ejemplo, un operador de planta apoyado por otro sensor)?
 
Figura 2. Efecto del TD Sobre la Disponibilidad de la SIF.
 
2-  Que la SIF esté en reparación. Nuevamente, dependiendo del nivel de redundancia, la reparación de algún elemento de la SIF pudiera dejar a la instalación sin la reducción de riesgo necesaria mientras la misma se está realizando. El Tiempo Medio para Reparar (MRT: Mean Repair Time) implica tanto la reparación en sí, como la obtención de los repuestos y herramientas para realizarla. Esta última por lo general es subestimada, haciendo que los cálculos de verificación del SIL de la SIF sean irreales. Este tiempo también debe ser estimado según las políticas de la instalación y reflejar las practicas reales de la misma. Un MRT de 8 horas para una falla que amerite desmontar una válvula de bloqueo (que implica detener el proceso), en muchos casos no parece muy adecuado. Adicionalmente, se debe tomar en cuenta el tiempo para detectar cual es la falla, que se incluye en el Tiempo Medio para Restaurar (MTTR: Mean Time to Restoration). En la figura 3 se muestra el efecto de las reparaciones sobre la disponibilidad de la SIF. Nota para el lector ¿Cuánto tiempo le lleva realizar una reparación promedio de un elemento de una SIF en su Instalación?
 
Figura 3. Efecto de las Reparaciones (MTTR y MRT) sobre la Disponibilidad de la SIF.
 
3-    Que la SIF esté fallada en forma peligrosa detectable por diagnóstico. Si la falla fue detectada mediante los diagnósticos de alguno de los elementos de la SIF se debe tomar en cuenta el Tiempo de Intervalo del Diagnostico Automático (TIA: Automatic Test Interval), ya que eso determinará lo que tardará el sistema en detectar la falla para realizar la notificación. Mientras eso sucede, la SIF posiblemente estará incapacitada de realizar su función. En la figura 4 se muestra como el diagnóstico y la subsecuente reparación afectan la disponibilidad de la SIF. Nota para el lector ¿Pueden las Pruebas de Recorrido Parcial (PST: Partial Stroke Test) considerarse para la estimación del TIA en su instalación?
 
Figura 4. Efecto del Diagnóstico (TIA) sobre la Disponibilidad de la SIF.
 
4-   Que la SIF esté fallada en forma peligrosa no detectable por diagnóstico. La lógica en este caso es la siguiente, si la SIF está fallada en forma que no existe un diagnostico capaz de evidenciar esa falla, entonces la SIF no está disponible para ofrecer seguridad y nadie puede darse cuenta de ello a menos que se pruebe. Es decir, la única forma de revelar las fallas peligrosas ocultas es mediante las pruebas periódicas que se realizan según el Tiempo de Inspección (TIM: Manual Test Interval) especificado en las SRS y usado en los cálculos de verificación del SIL. Este parámetro es directamente proporcional a la probabilidad de falla peligrosa de la SIF, es decir, mientras más grande el intervalo más grande es la probabilidad de que la SIF falle en el momento que se le necesite. De allí la tentación de usar TIM irrealmente bajos en el diseño y que son imposibles de cumplir por las organizaciones en la operación. Recuerde, no es lo mismo diseñar (el papel aguanta todo) que operar y mantener. Debe haber un equilibrio entre los objetivos de producción y de seguridad, que le permita a la organización generar una política consistente para la implementación de TIM realizables y que sean monitoreados para que se ajusten a los constantes cambios dentro de la organización sin impactar la seguridad. En la figura 5 se muestra el efecto del intervalo de pruebas periódicas sobre la disponibilidad de la SIF. Nota para el lector ¿Cada cuánto su instalación realiza una parada de planta que le permita probar apropiadamente las SIF? ¿Coincide este tiempo con el especificado en el diseño de las SIF?
 
Figura 5. Efecto de la Intervalo de Pruebas Periódicas (TIM) Sobre la
Disponibilidad de la SIF.
 
5- Que los elementos de la SIF nunca hayan sido reemplazados. Si los elementos de la SIF no han sido reemplazados, las fallas asociadas a las tasas de fallas que no pueden ser detectadas, ni por diagnósticos automáticos ni por pruebas manuales, se estarán acumulando durante la vida útil de la SIF. Por esto se debe estimar cual será el Tiempo de Misión (Mission Time) de cada componente de la SIF y el mismo debe ser respetado. En la figura 6 se muestra el efecto del Tiempo de Misión sobre la disponibilidad de la SIF. Nota para el lector ¿En cuánto tiempo tiene planificado el reemplazo de los sensores de su SIF?
 
 
Figura 6. Efecto del Tiempo de Misión sobre la Disponibilidad de la SIF.
 
Estos son solo algunos ejemplos, así que por favor tómese su Tiempo cuando defina las políticas en su organización para la implementación de estos parámetros.
 
Esta entrada fue basada en un trabajo de mi amigo Ricardo A. Vittoni, TIME- The Most Importat Parameter in SIS Fucntionality, mi reconocimiento y agradecimiento a él.
 
PONGA A PRUEBAS SUS CONOCIMIENTOS.
Preguntas de esta entrada:

Seguridad Funcional, una cuestión de tiempo Leer más »

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

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

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

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

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

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

 

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

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

 HFT según IEC 61508

Si se decide seguir lo lineamientos de IEC 61508, la relación de HFT y SIL viene definida por el SFF del elemento o subsistema. En las tablas siguientes definen esta relación en función del tipo de dispositivo A (simple) o B (complejo).

 

Tabla
1. Tolerancia de Falla por Hardware. Dispositivos Tipo A. IEC 61508
-2010

SFF

Tolerancia
de falla de Hardware (Hardware Fault Tolerance)

0

1

2

< 60 %

SIL 1

SIL 2

SIL 3

60 a 90 %

SIL 2

SIL 3

SIL 4

90 % a 99 %

SIL 3

SIL 4

SIL 4

99 %

SIL 3

SIL 4

SIL 4

 

Tabla
2. Tolerancia de Falla por Hardware. Dispositivos Tipo B. IEC 61508
-2010

SFF

Tolerancia
de falla de Hardware (Hardware Fault Tolerance)

0

1

2

< 60 %

No sepermite

SIL 1

SIL 2

60 a 90 %

SIL 1

SIL 2

SIL 3

90 % a 99%

SIL 2

SIL 3

SIL 4

99 %

SIL 3

SIL 4

SIL 4

 

HFT según IEC 61511

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

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

SIL

Mínimo HFT Requerido

1 (Cualquier modo)

0

2 (Modo Bajo demanda)

0

2 (Modo continuo)

1

3 (Alta demanda, o modo continuo)

1

4 (Cualquier modo)

2

Votación y Redundancia

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

N Expresa el número de votación

M expresa la redundancia

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

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

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

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

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

HFTs=N-1.

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

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

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

 

PONGA A PRUEBA SUS CONOCIMIENTOS.

 Preguntas de esta entrada:

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

 

 

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

Comencemos por el principio: Las 3 “S” de la Seguridad Funcional

Hablar de Seguridad Funcional nos remite, en forma casi inmediata, a tratar los conceptos relacionados con las 3 “S”, Sistema Instrumentado de Seguridad (SIS), Funciones Instrumentadas de Seguridad (SIF) y Nivel de Integridad de Seguridad (SIL), que, a pesar de ser conceptos básicos, usualmente suelen ser confundidos y no empleados con claridad.

Podríamos ponerlo en perspectiva de la siguiente manera (para ir de lo general a lo específico), el SIS es quien soporta, contiene o donde están implementadas todas las SIF; y la SIF es la función que dará la prestación de seguridad al proceso, en función del desempeño establecido a través del SIL. Entendiendo que el SIL es una característica de la SIF y no del SIS, por lo que uno debe determinar el SIL de cada SIF del SIS.

La relación entre el SIS, las SIF y su SIL correspondiente es mostrada en la figura 1. Este ejemplo nos presenta un SIS que aloja tres SIF diferentes, dos de ellas con requerimiento de desempeño SIL 1 y una SIL2. Donde todas comparten
un componente común, que es el controlador de seguridad.

 

Figura 1. Relación SIS, SIF y SIL

 

Ahora bien, detallemos cada término.

SIS: Sistema instrumentado usado para realizar una o más Funciones Instrumentadas de Seguridad (IEC 61511-1: 2016 – 3.2.67).

El SIS, por lo general, está compuesto por varias Funciones Instrumentadas de Seguridad (SIF) y todos los servicios comunes y necesarios para su funcionamiento. En el mismo se prestan los servicios básicos de soporte común para alojarlas, es decir, el alojamiento físico (por ejemplo, chasis para las tarjetas de E/S o alojamiento del procesador común), alojamiento lógico (por ejemplo, alojamiento del programa de aplicación), servicio común como alimentación eléctrica, etc.

SIF: Función de seguridad a ser implementada por un Sistema Instrumentado de Seguridad (SIS) (IEC 61511-1: 2016 – 3.2.66).

La SIF es considerada un sistema formado por al menos tres (3) sub-sistemas: el sub-sistema de detección (compuesto a su vez por un conjunto de uno o más elementos de medición o detección), el sub-sistema lógico (comúnmente un Controlador Lógico Programable de Seguridad, pero que puede estar compuesto por uno o más dispositivos lógicos de seguridad, inclusive no programables) y el elemento final (que puede estar compuesto por una o más válvulas, motores, etc. y sus accesorios). En resumen, debe existir, quien mide la variable, quien ejecuta la lógica y quien actúa para llevar al proceso a un estado seguro.

Una adecuada descripción de la SIF debe indicar:

  • ¿Qué detecta? (Detección)
  • ¿Qué actúa? (Actuación)
  • ¿Cuál es la relación entre la detección y la actuación? (Lógica)
  • ¿Cuánto tiempo está disponible para actuar? (Tiempo de Actuación)
  • ¿Cuál es el requerimiento de reducción de riesgo asociada? (FRR/SIL)
  • ¿Cuál es el estado seguro del proceso?

Un mal ejemplo de descripción de una SIF sería: La función de seguridad de presión del separador deberá evitar la sobre presión de las líneas de baja presión hacia la tranquilla de aguas residuales.

Un buen ejemplo, seria: Medir la presión en el separador de entrada XYZ con el transmisor PZT-001 y si la presión excede los 250 PSI, cerrar la válvula de bloqueo de entrada del separador XV-001 durante los 3 segundos siguientes a la detección de esta condición y así evitar la entrada de más material al separador. El nivel de integridad requerido es SIL2.

Pero podemos encontrar más de un tipo de SIF según su modo de operación:

  • Las Funciones Instrumentadas de Seguridad en Modo Demanda: Son aquellas en las cuales un evento de peligro se presenta solo si en la existencia de una demanda de proceso la SIF se encuentra en falla o la misma falla en el momento de tratar de llevar al proceso al estado seguro.  Pueden ser de dos tipos:
    • Función Instrumentada de Seguridad Modo Bajo Demanda: Modo de operación donde la SIF actúa en demanda para llevar al proceso a su estado seguro y donde la frecuencia de la demanda no es mayor a una vez por año (IEC 61511-1: 2016 – 3.2.39.a).
    • Función Instrumentada de Seguridad Modo Alta Demanda: Modo de operación donde la SIF actúa en demanda para llevar al proceso a su estado seguro y donde la frecuencia de la demanda es mayor a una vez por año (IEC 61511-1: 2016 – 3.2.39.b).
  •  Función Instrumentada de Seguridad Modo Continuo: Modo de operación donde la SIF efectúa un control continuo para llevar al proceso a su estado seguro (IEC 61511-1: 2016 – 3.2.39.c). En caso de un fallo peligroso de la SIF y la inacción de alguna otra capa de protección el evento de peligro se presentará de forma inmediata. La falla peligrosa de la SIF es en si es la demanda del proceso ya que hace funciones de control y de seguridad al mismo tiempo.

A cada SIF se le debe asignar un Nivel de Integridad de Seguridad (SIL), en relación con otras capas de protección que participan en la reducción del mismo riesgo. Esta es una característica única de la SIF, es decir, solo ella posee SIL, no el instrumento, no el proceso, no la planta, no el controlador. Solo la SIF posee un SIL determinado.

SIL: Valor discreto de 1 a 4, que define los requerimientos de integridad de seguridad que deben ser alcanzados por cada SIF ejecutada por el SIS (IEC 61511-1: 2016 – 3.2.69).

La integridad de seguridad comprende la integridad de seguridad del hardware y la integridad de seguridad sistemática. El valor 1 a 4 define el orden de magnitud de la reducción de riesgo que provee la SIF. El nivel 4 tiene el nivel más elevado de integridad de seguridad e indica una reducción de riesgo del orden de 4 ceros (más de 10.000); la integridad de seguridad del nivel 1 tiene el más bajo e indica una reducción de riesgo del orden de 1 cero (más de 10).

La meta de desempeño dependerá del modo de operación de la SIF, para modo bajo demanda se usarán metas basadas en la Probabilidad de la Falla en Demanda Promedio de la SIF (PFDavg), siguiendo la tabla 1. Para los modos de operación alta demanda y continuo se usarán metas basadas en la tasa de falla peligrosa por hora de la SIF (PFH), siguiendo la tabla 2.

Tabla 1. Nivel de Integridad de
Seguridad (Modo Bajo Demanda)

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

 Tabla 2. Nivel
de Integridad de Seguridad (Modo Continuo y Alta demanda)

Nivel de Integridad de Seguridad
(SIL)

Frecuencia media de fallos
peligrosos (por hora)

4

10−9 a <10−8

3

10−8 a <10−7

2

10−7 a <10−6

1

10−6 a <10−5

 

 En siguiente entrada del Blog, trataremos los conceptos de Redundancia y Fracción de Falla Segura y Restricciones de Arquitectura……

 PONGA A PRUEBAS SUS CONOCIMEINTOS.

Preguntas de esta entrada:

1-     El SIL 4 puede ser usado en la industria de los procesos:

a.      Si

b.      No

c.      Depende del nivel de peligro de la instalación

 

2-     Una buena definición de una SIF debe responder las siguientes interrogantes:

a.  ¿Quién sensa?, ¿Quien actúa?, ¿Cuál es la relación lógica?, ¿Cuál es el SIL?, ¿Cuál es el tiempo para actuar?, ¿Cuál es el estado seguro del Proceso?

 

b.  ¿Cuál es el transmisor / Switch?, ¿Cuál es el PLC de Seguridad?, ¿Cuál es la Válvula o elemento final?

 

c.  ¿Cuál es la Matriz Causa y Efecto?

 

 

Comencemos por el principio: Las 3 “S” de la Seguridad Funcional Leer más »

¿Qué es y cómo se logra la integridad de la Seguridad Funcional?

Siguiendo con los conceptos básicos en materia de Seguridad Funcional, les prometí escribir sobre la Integridad de la Seguridad o en nuestro ámbito Integridad de la Seguridad Funcional.

En primera instancia desglosemos el concepto en un par de términos básicos.

Integridad: De integro; “que está completo“ y “que no carece de ninguna de sus partes“ (DRAE) y Seguridad (Safety): “Ausencia de riesgo inaceptable” (IEC61508:2010 | 3.1.11) o “Ausencia de riesgo no tolerable” (61511:2016 | 3.2.64).
Para diseñar, mantener y operar un sistema relacionado con la seguridad, como un Sistema Instrumentado de Seguridad (SIS), que pueda ofrecer seguridad en una forma íntegra, es decir completa, deben tomarse en cuenta todos los factores que puedan afectarla, esto
es, se deben tomar en cuenta todas las causas que puedan hacer que el SIS se vea inhabilitado de poder ejercer, en forma adecuada, la función para la cual ha sido construido.
Así que, para que un SIS pueda alcanzar la integridad de la seguridad para la cual está diseñado, deben ser controladas
o evitadas todas las fallas aleatorias (normalmente asociadas al hardware) y todas las fallas sistemáticas (normalmente asociadas con el software y el diseño). El manejo de fallas, tanto aleatorias como sistemáticas, fue previsto por quienes desarrollaron las normativas basadas en desempeño, creando disposiciones que permitan gestionar en forma efectiva ambos tipos de fallas.
Esto nos lleva a por lo menos dos conceptos más:
Primero, la Integridad de Seguridad del Hardware, que es entendida como “la parte de la integridad de seguridad del SIS relativa a fallas aleatorias de hardware en un modo de falla peligrosa” (61511:2016 | 3.2.26). Para lograr la Integridad de Seguridad del Hardware, se
han establecidos los Niveles de Integridad de Seguridad conocidos como SIL (Safety Integrity Level), como una medida de reconocer que ningún sistema es capaz de ofrecer un 100% de integridad de seguridad (un sistema infalible), pero sí nos podemos acercar en
buena medida a ese valor, en función de la reducción de riesgo que es capaz de ofrecer cada aplicación (SIL1, SIL2…etc.).
Segundo, la Integridad de Seguridad Sistemática entendida como “la parte de la integridad de seguridad del SIS relativa a fallas sistemáticas en un modo de falla peligrosa” (61511:2016 | 3.2.26). Estos tipos de fallas son normalmente difíciles de establecer o cuantificar y en ocasiones solo se pueden considerar cualitativamente, por esta razón, surge la necesidad de hacer un enfoque sistemático como el del Ciclo de Vida de Seguridad. Para lograr la Integridad de Seguridad Sistemática se deben seguir los lineamientos del Ciclo de Vida de Seguridad, que para el usuario final y el consultor/integrador son mostrados en la IEC-61511 y para los fabricantes en la IEC-61508, y es expresada a través de la Capacidad Sistemática (SC: Systematic Capability) del equipo ofrecido, como señal de que el fabricante ha cumplido con su parte.
Como vemos, no hay forma de lograr la Integridad de la Seguridad si no ponemos atención tanto a la gestión de las fallas aleatorias, como a las fallas sistemáticas como un todo.
Adicionalmente, les dejo las referencias originales de las normativas:
Integridad de Seguridad: Probabilidad media de que un sistema instrumentado de seguridad realice satisfactoriamente las funciones instrumentadas de seguridad en todas las condiciones establecidas dentro de un periodo de tiempo establecido. (IEC 61511 2003 | 3.2.73)
Integridad de Seguridad: Habilidad del SIS para realizar una SIF según sea especificada y cuando sea requerida. (IEC 61511 2016 | 3.2.68)
Integridad de Seguridad: Probabilidad de que un sistema E/E/PE relacionado con la seguridad ejecute de forma satisfactoria las funciones de seguridad requeridas en todas las condiciones especificadas en un periodo de tiempo especificado. (IEC 61508 2010 | 3.5.4)
 
En siguiente entrada del Blog, trataremos los conceptos de SIL, SIS y SIF…
 
PONGA A PRUEBAS SUS CONOCIMEINTOS.
 
           1. La integridad de la Seguridad del SIS está relacionada a:
a.     Las fallas del Hardware y su PFD
b.     Las Fallas del Software
c.     Las Fallas Aleatorias y las Fallas Sistemáticas 
 
2. La integridad de la Seguridad Sistemática es gestionada a través de:
a.     Del cálculo del SIL
b.     Del Ciclo de Vida de Seguridad
c.     Del uso de Capas de protección



Responda las preguntas de comprobación AQUÍ

¿Qué es y cómo se logra la integridad de la Seguridad Funcional? Leer más »

Comencemos por el principio: ¿Qué es Seguridad Funcional?

Para ser un blog cuya temática es presentar contenidos relativos a la Seguridad Funcional de los Sistemas Instrumentados de Seguridad en  nuestro idioma, pues me pareció oportuno iniciar por tratar el concepto de Seguridad Funcional en mi primera entrada.

Existen un buen número de referencias respecto al concepto Seguridad Funcional y para establecer el contexto podemos citar algunos:
Para la norma IEC 61508:2010 la Seguridad Funcional es:
“Parte de la seguridad global que se refiere al EUC y al sistema de control del EUC que depende del funcionamiento correcto de los sistemas E/E/PE relacionados con la seguridad y de otras medidas de reducción del riesgo” (3.1.12).
Mientras que para la norma IEC 61511:2016 es:
Parte de la seguridad general relativa al proceso y alBPCS que depende del correcto funcionamiento del SIS y de otras capas de protección” (3.2.23).
Otras fuentes son:
HSE: “… es la parte de la seguridad global de las instalaciones que depende del correcto funcionamiento de los sistemas relacionados con la seguridad y otras medidas de reducción de riesgos como los sistemas instrumentados de seguridad (SIS), los sistemas de alarma y los sistemas básicos de control de procesos (BPCS)”
TÜV Rheinland: … es la parte de la seguridad global que depende de que un sistema o equipo funcione correctamente en respuesta a sus entradas” ……..es la detección de una condición potencialmente peligrosa que resulta en la activación de un dispositivo o mecanismo protector o correctivo para evitar que se produzcan eventos peligrosos o proporcionar mitigación para
reducir las consecuencias del evento peligroso”
TÜV SÜD: …. es la parte de la seguridad general de un sistema o equipo que depende del sistema o equipo que funcione correctamente en respuesta a sus entradas, incluyendo la gestión segura de errores probables del operador, fallas de hardware y software y cambios ambientales”
UL: “… es la parte crítica de la seguridad general de un sistema o producto que depende de la ejecución correcta de comandos y funciones específicos”
CSA: “…. se describe como la representación de productos o sistemas cuya falla en el funcionamiento confiable puede dañar a las personas, la propiedad o el medio ambiente”
David Smith: “Se utiliza para referirse a la fiabilidad (conocida como integridad en el mundo de la seguridad) de los equipos relacionados con la seguridad. En otras palabras, se refiere a la probabilidad de que funcione correctamente, de ahí la palabra funcional”
Podríamos inclusive nombrar a Wikipedia, que publica que: “…se refiere a la parte de la seguridad global de un sistema consistente en que sus componentes o subsistemas eléctricos, electrónicos y programables con implicaciones en materia de seguridad respondan de forma adecuada ante cualquier estímulo externo, incluyendo errores humanos, fallos de hardware o cambios en su entorno”
Ahora bien, formarse un concepto un poco más simple creo que se requiere del auxilio de algunos otros conceptos:
El primero de ellos es el concepto de Seguridad (Safety), que según la norma IEC 61508:2010 es “Ausencia de riesgo inaceptable” (3.1.11) y según IEC 61511:2016 es “Ausencia de riesgo no tolerable” (3.2.64).
Adicionalmente, creo necesario estudiar el concepto de Función de Seguridad, que según la norma IEC61508:2010 es “Función a realizar por un sistema E/E/PE relacionado con la seguridad o por otras medidas de reducción del riesgo, que está destinada a lograr o mantener un estado seguro del EUC con respecto a un evento peligroso específico” (3.5.1) y según IEC 61511:2016 es “Función a ser implementada por una o más capas de protección, la cual está destinada a lograr o mantener un estado seguro para el proceso, con respecto a un evento peligroso específico” (3.2.65).
Y estos a su vez no llevan a los conceptos de sistema E/E/PE relacionado con la seguridad (IEC 61508) y otras medidas de reducción del riesgo (IEC 61508) o capa de protección (IEC 61511).
Sistema relacionado con la seguridad: “Un sistema así designado es un sistema que, simultáneamente:
  • Implementa las funciones de seguridad requeridas necesarias para lograr o mantener un estado seguro del EUC; y
  • Está previsto para alcanzar, por sí mismo o con otros sistemas E/E/PE y otras medidas de reducción del riesgo, la integridad de seguridad necesaria para las funciones de seguridad requeridas.” (IEC 61508:2010 3.4.1).
Otras medidas de reducción del riesgo: “Medida para reducir o mitigar el riesgo que está separada, es distinta y no utiliza los sistemas E/E/PE relacionados con la seguridad” (IEC 61508:2010 3.4.2).
Capa de protección: “Cualquier mecanismo independiente que reduzca el riesgo mediante el control, la prevención o la mitigación” (IEC 61511:2016 3.2.57).
De manera simplificada podría decir que la Seguridad Funcional es la que depende de la(s) Función(es) de Seguridad asociada a un peligro particular.
El término manejado por las otras referencias citadas, diferentes a las normas, solo se refieren a la Seguridad Funcional que depende de los sistemas E/E/PE relacionados a la seguridad o el SIS.
En este caso particular, se podría decir entonces que la Seguridad Funcional es la que depende de que un sistema (hardware y software) especificado para brindar seguridad, funcione (responda adecuadamente a los estímulos de entrada y genere las salidas requeridas). El sistema debe responder de manera satisfactoria tanto a condiciones externas (demandas del proceso, condiciones ambientales) como a fallos internos (fallas sistemáticas, aleatorias o de causa común) para asegurar que no resulten en daños a personas, el ambiente, las instalaciones y/o la producción.
Y esto nos lleva al concepto de Integridad de Seguridad, pero este lo trataremos en la siguiente entrada del Blog…
PONGA A PRUEBAS SUS CONOCIMEINTOS.
Preguntas de esta entrada:
1-  ¿Mencione al menos 5 sistemas, conocidos como Otras Medidas de Reducción de Riesgo u Otras Capas de Protección en la industria de los procesos?
2-  ¿Mencione al menos 5 Sistemas, conocidos como sistemas E/E/PE relacionados a la seguridad o el SIS en la industria de los procesos?

Referencias

Norma IEC 61508 (2010).
Functional safety of electrical/electronic/programmable electronic
safety-related systems
Norma IEC 61511 (2016).
Functional safety – Safety instrumented systems for the process industry
sector.
Smith, D (2011). Safety Critical
Systems Handbook
http://www.ul.com/es/
www.ul.com/es/
Ing. Esp. Romel R. Rodríguez A.
CSF. Consultoría en Seguridad Funcional
FSEng TÜV Rheinland 575/07 | FSEng TÜV SÜD TP15051090
ISA84 SIS
Fundamentals Specialist | PHA Leader

Comencemos por el principio: ¿Qué es Seguridad Funcional? Leer más »