Seguridad Funcional

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

Gestión de la Seguridad Funcional / /

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

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

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

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

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

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

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

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

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

Eduardo Sánchez

FSEng TÜV SÜD TP18051531

Romel Rodríguez

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

¿Por qué es necesario tener un Sistema de Gestión de la Seguridad Funcional? Leer más »

Equipamiento del SIS ¿Qué debo considerar?

SRS / /

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Rigleth S. Gragel V.

Ingeniero de Seguridad Funcional

FSCP TÜV SÜD TP18051520

 Romel Rodriguez

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

 

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

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

Gestión de 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 »

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 »

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

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

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

Diseño / /
La calidad del modelo que se crea para representar una Función Instrumentada de Seguridad (SIF) es altamente dependiente de la calidad de los datos que usemos para hacer la predicción de su comportamiento; bien sea calculando la Probabilidad de Falla en Demanda Promedio (PFDavg) o la Frecuencia de Fallas por Horas (PFH). Es una preocupación genuina, para quienes tienen la responsabilidad de cuantificar la falla aleatoria de la SIF, la necesidad de buscar el dato que les permita hacer la mejor representación posible.
 
La norma IEC-61511-2016 en su cláusula 11.9.3, describe claramente que: 

“Los datos de confiabilidad utilizados para cuantificar la tasa de fallas aleatorias deben ser creíbles, trazables, documentados y justificados y se basarán en la información de campo de dispositivos similares utilizados en entornos operativos similares”.

La intención de incluir esta cláusula en la versión 2016 es hacer énfasis justamente en la calidad del dato que se debe usar.
 
Pero, ¿qué quiere decir con que la tasa de falla sea creíble? La tasa de falla debe tener un valor que corresponda con el tipo de equipamiento y la realidad operacional donde se pretende utilizar. Usar datos que se puedan considerar muy optimistas y que resulten en modelos de SIF con prestaciones muy altas (muy bajas PFDavg /PFH o SIL muy altos) ocasionará una percepción de una reducción de riesgo errónea, exponiéndonos a un accidente potencial. Cada familia de equipamiento tiene unos valores máximos y mínimos que son considerados válidos para un ambiente operativo particular. Recordemos que una tasa de falla no es un valor único sino un valor tomado de una colección de valores (puede ser la media) que representan el comportamiento estadístico del equipo en particular. Bases de datos como OREDA, CCPS, IEEE y EXIDA pueden expresarlos de diversas maneras, una curva normal o valores máximos y mínimos. Así que la próxima vez que vea un dato muy optimista piénselo dos veces y compárelo.
 
¿Qué debemos buscar sobre la procedencia del dato?, ¿Qué quiere decir con que la tasa de falla sea trazable? Cuando una organización publica un valor de tasa de falla, tiene el deber de explicar cómo se obtuvo: Si se estimó basado en datos de campo (¿en qué condiciones operativas y ambientales?) o en base al retorno de partes a fabricantes o en predicciones basadas en técnicas como Análisis de Modos y Efectos de Fallas y Diagnósticos (FMEDA) o inclusive en técnicas combinadas de estimación y predicción (por ejemplo, usando teoremas de Bayes).
 
¿Cómo debe ser la fuente de donde obtenemos el dato? ¿Qué quiere decir con que la tasa de falla sea documentada? La organización que publica un dato no solo debe decir de dónde proviene sino, además, debe indicar cómo es el proceso mediante el cual se obtuvo. Si la tasa de falla proviene de un proceso de recolección de datos en campo, se debe indicar cuál es el esquema utilizado para documentar ese proceso (ISO 14224, IEC 60300 3-2-2004, BS 13460, PERD, OREDA) y si es de una predicción, se debe indicar qué método se utilizó (B10, FMEDA); es fundamental que se de fe que el proceso de generación del dato fue realizado de manera organizada y estructurada y permite documentar la fuente del dato, el proceso de generación y el reporte del mismo.
 
Finalmente, el uso de una tasa de falla particular es decisión de quien hace el modelado de la SIF y es éste quien tiene que justificar la escogencia de un dato en específico. La decisión es suya. Entonces, ¿qué quiere decir con que la tasa de falla sea justificada? La justificación de escogencia debe atender a la mejor representación de su realidad operacional, entorno ambiental, políticas de gestión de integridad mecánica de los sistemas, etc.
 
Como consejo final, tómese su tiempo para verificar si las tasas de falla que va a escoger podrán ser justificadas, si son creíbles, trazables, están bien documentadas y están basadas en datos de campo en condiciones operacionales similares, permitiéndole asegurar que su diseño estará conforme con el SIL objetivo.
 
Hasta una próxima oportunidad,
Autores:
José Luis Mota – SOIVEN
FSEng TÜV SÜD TP18051527
Romel Rodriguez – CSF
Functional Safety Expert TÜV SÜD TP18010990 | ISA84/IEC 61511 Expert | FSEng TÜV Rheinland 575/07 | PHA Leader

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

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

Gestión de la Seguridad Funcional / /
Debemos reconocer cuán importante es el tema de la seguridad funcional y la tendencia de procesos productivos utilizando tecnología cada vez más compleja; sistemas de seguridad con mayores rendimientos y migraciones de funciones de seguridad mecánicas a unidades
con controles electrónicos. Pero, trabajar en seguridad funcional es algo más que un trabajo rutinario, es una integración entre la comprensión de las normas relacionadas, la gestión y planificación de un ciclo de vida de seguridad, y el manejo de parámetros relacionados con la seguridad en varios niveles. Por esa razón, en esta oportunidad continuaré con el tema de mi post Trabajando en Seguridad Funcional: La Gestión de las Competencias del Personal.
La norma de seguridad funcional para la industria de los procesos IEC 61511 establece que las organizaciones que tengan responsabilidad de una o más fases del ciclo de vida de seguridad del SIS deben desarrollar y disponer de un mecanismo para gestionar las competencias de su personal. Los involucrados en alguna de las fases del ciclo de vida de seguridad de los SIS deben ser competentes para realizar las
actividades de las que son responsables, y ya sabemos que la competencia va más allá de la formación técnica para adquirir conocimientos, implica el entendimiento de la operación del SIS, la comprensión de procedimientos y prácticas de trabajo, así como, comportamiento, actitudes y habilidades para asumir responsabilidades.
Un sistema de gestión de competencias involucra políticas, procedimientos y prácticas diseñadas para desarrollar, medir, mantener y mejorar continuamente las competencias del personal dentro de una organización. Es necesario analizar la naturaleza de la actividad y definir criterios medibles, según los cuales evaluar o juzgar el desempeño de cada persona. A las tareas específicas de cada actividad se les debe atribuir un criterio de competencia, ofreciendo una visión de la forma correcta de realizar una tarea, las habilidades técnicas, conocimientos y atributos personales requeridos por cada rol.
Al definir el perfil de competencia mínimo que debe ser cubierto por cada rol, se puede asegurar que los trabajadores tienen los atributos necesarios para realizar sus tareas; incluida la posibilidad de demostrar a reguladores, auditores y, en ocasiones a clientes, que las competencias del personal se están gestionando de forma efectiva.
Así, es posible evaluar de forma individual las capacidades de cada integrante del equipo, y si cumple con el perfil especificado, la persona se considera competente para el rol en particular. En caso que la persona no cubra las competencias requeridas, no podrá ser asignada a esa tarea y será necesario un plan de capacitación para desarrollar su potencial. De igual forma, si una persona demuestra un nivel de competencia más alto que el requerido, debe ser considerado en futuras
evaluaciones.
Como vemos en las situaciones descritas a continuación, cualquier actividad relacionada con la seguridad funcional que sea realizada por personal con conocimiento limitado, sin la experiencia adecuada o una actitud displicente, puede resultar en sistemas con una integridad de seguridad inadecuada:
  • Análisis de peligros y riesgos sin la identificación adecuada de escenarios peligrosos y estimación inadecuada del riesgo (con riesgos mayores a los que realmente pueden ser tolerados) o la generación de recomendaciones que no son necesarias.
  • Identificación inadecuada de capas de protección independientes (IPL) durante las sesiones de LOPA, resultando en una estimación errónea del nivel de integridad de seguridad (SIL) requerido.
  • Omisión de parámetros claves en el desempeño del sistema; por ejemplo, tiempo de actuación de la función instrumentada de seguridad (SIF), durante la especificación de los requerimientos de seguridad.
  • Falta de conocimiento sobre el tratamiento que debe ser aplicado a las IPL consideradas en el diseño para garantizar la reducción de riesgo que debe ofrecer cada SIF.
  • Instalación y/o calibración inadecuada de equipos o instrumentos asociados al sistema instrumentado de seguridad (SIS) por desconocimiento del personal encargado.
  • Degradación del desempeño del SIS por falta de comprobación de las premisas de diseño durante la operación y mantenimiento o incumplimiento de los plazos estimados de pruebas.
  • Modificaciones en las condiciones de proceso, hardware, software, procedimientos, etc. sin evaluar el impacto sobre la integridad de la seguridad del SIS.
Es importante comunicar efectivamente las deficiencias encontradas al evaluar el desempeño – debemos proporcionar una visión clara de qué competencias se necesitan, evitar la sobrestimación de habilidades y promover medidas de capacitación – debido a que, dada la relación entre cada actividad, las tareas que no se realicen de forma apropiada pueden afectar la seguridad a nivel global.
Nuestra meta debe ser reducir la probabilidad de que se pase por alto un desempeño deficiente, permitir que se tomen medidas que eviten el deterioro de las potencialidades de cada integrante del equipo y garantizar la mejora continua del sistema de gestión de competencias.

Trabajando en Seguridad Funcional: La Gestión de las Competencias del Personal II Leer más »

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

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

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

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

Desviaciones:

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

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

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: ¿Qué significa verificar?

Gestión de la Seguridad Funcional / /

 

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 »