El Futuro de los SIS


Gene Cammack, PE; Francisco Sánchez, PDVSA y Luis M. García G. CFSE
Editado en Español por César A. Platero D.
InTech México Automatización,   
Edición  Octubre – Diciembre 2009.

INTRODUCCIÓN

Universalmente encontramos que ha habido una aceptación y adopción generalizada de los conceptos fundamentales en la seguridad funcional en plantas de procesos continuos, como la forma de afrontar adecuadamente los riesgos inherentes a dichos procesos, es decir, el control seguro de las operaciones. Muy en particular la norma ANSI/ISA 84.00.01-2004 (lEC 61511 Mod.) ha sido reconocida como el estándar a seguir, puesto que define la implementación de todo el ciclo de vida de seguridad funcional y como diseñar Sistemas Instrumentados de Seguridad (SIS) para la industria de procesos continuos.

Sin embargo, dicha implementación ha sido limitada a la función de proteger procesos en estado estable, y raramente en arranques de plantas, paradas de emergencia o transiciones dinámicas en el proceso. La secuenciación ha sido casi siempre considerada como una función manual y a discreción de los operadores, en seguimiento de los manuales de procedimientos y experiencia propia.

Paradójicamente, los arranques, las paradas y las transiciones dinámicas siempre han sido considerados como las etapas más críticas y peligrosas de toda la operación en la industria de procesos continuos. Siendo este el caso; ¿Cuál es la razón detrás de la suspensión de los sistemas de seguridad durante estos periodos? Más aún; ¿Es esta razón válida? Por último nos preguntamos si nuevos desarrollos tecnológicos nos pueden permitir resolver algunas de estas razones a la hora de diseñar permisivos como, por ejemplo, en el arranque de una planta.

SECUENCIA DE PERMISIVOS

Programados a partir de una serie de condiciones operacionales en estado estable, además de una serie de restricciones, los SIS son una capa de protección independiente por encima del Sistema Básico de Control de Proceso (SBCP) y el equipo de operadores.

Aunque estén bien diseñados para proteger en condiciones estables, el alcanzar dicha condición incluye secuencias de permisivos. “Bypassing”, inhibir o enmascarar salidas y entradas en los SIS es una práctica común durante estos periodos en las plantas.  En este caso entonces, las Funciones Instrumentadas de Seguridad (FIS) son temporalmente suspendidas hasta alcanzar la estabilidad.

Para entender las razones detrás de esta práctica limitante de las funciones de un SIS, debemos primero entender que envuelve la implementación de un permisivo: Las secuencias permisivas tienen tres características:

  • Su dependencia del tiempo debe ser considerada
  • Las variables están cambiando tanto como como los puntos o límites de disparo
  • Los enclavamientos varían y deben ser inhibidos o forzados

¿QUÉ SE ASUME PARA JUSTIFICAR LA SUSPENSIÓN DE UNA FIS?

Existen cinco razones que se esgrimen para explicar y así justificar la suspensión de una FIS durante transiciones en el proceso: (Nota: “Bypass” o “Ignorar”)

  • Transiciones en los procesos continuos (como arranques) no son frecuentes y además duran muy poco comparadas con el tiempo en el cual el proceso está en estado estable. Por tanto las FIS pueden ser suspendidas de acuerdo a un procedimiento escrito en un manual de operaciones y la presencia y supervisión de alguien con autoridad jerárquica como por ejemplo un “Responsable de puesta en marcha”.
  • No hay similitud suficiente entre procesos diferentes para justificar el desarrollo de estándares más prescriptivo, como el desarrollo de prácticas recomendadas. Esto hace parecer aceptable el manejar estos periodos manualmente, bajo condiciones especiales.1
  • No hay similitud entre las operaciones de transición y las operaciones en estado estable. Los SIS son por lo tanto diseñados para operar bajo condiciones estables donde la mayoría de las operaciones ocurren. De otra forma habría que crear un SIS separado y en conflicto con el anterior para proteger y manejar el proceso durante las transiciones de proceso.
  • Las operaciones de transición en el proceso están más afectadas por la “Subjetividad” operativa y procedimientos que las operaciones durante el estado estable. Por ejemplo: ¿Cuánto tiempo debe un enclavamiento estar restringido? Por tanto el automatizar las transiciones requiere de un profundo conocimiento del proceso en la etapa de desarrollo.
  • Debido a que las transiciones son secuenciales y dinámicas, el tiempo de duración de cada enclavamiento o FIS en cada paso así como los cambios en los mismos son críticos. Por tanto estos cambios son difíciles de certificar y validar a menos que se tenga un conocimiento profundo del proceso, operaciones y adecuadas rutinas de simulación.

CUESTIONAMIENTO DE RAZONES EXPUESTAS

A pesar de lo validas que parezcan estas razones, pues parecen tener un trasfondo práctico, si se examinan detalladamente basándose en los fundamentos de la seguridad funcional de procesos continuos, se llega a la conclusión opuesta. Veamos una por una:

  • Las transiciones no son frecuentes y duran poco. Las transiciones, por su propia naturaleza, representan los momentos más volátiles o inestables en procesos continuos. Las variables pueden cambiar significativamente, tanto así que el SBCP puede que no tenga la capacidad o no esté bien ajustado para manejar adecuadamente tales cambios. Estos son momentos demasiados peligrosos como para dejarlo todo en manos de un operador o un equipo de operadores, aunque simplemente sea por la cantidad de variables que deben monitorear y acciones que deben ejecutar. La complejidad durante los periodos de transición (tiempos, límites dinámicos y cambiantes, alarmas, etc), requiere de la máxima atención del operador, y el pedirle que a la vez provea de una capa de protección encima de la operación en la cual está enfocado, definitivamente incrementaría el riesgo a niveles peligrosos. Por otra parte, es reconocido que el factor humano condiciona poderosamente el valor del Factor de Reducción de Riesgo (FRR)2. Una capa de protección debe ser fiable (aplicar cuando se precisa) y auditable. Ninguna de estas características pareciera aplicar a un “Bypass”, o el forzamiento de una salida. Menos aun cuando las variables están fuera de control y los puntos de disparo están continuamente cambiando. Definitivamente este no es el momento apropiado para depender de una capa de protección poco fiable (menos segura), puesto que si bien el tiempo de exposición es corto, la tasa de demanda es definitivamente muy alta.
  • No hay similitud entre diferentes procesos. Si bien es cierto que la falta de similitud entre procesos incrementa la dificultad de implementar SIS, esto no nos exime de la responsabilidad que tenemos de asegurarnos que el proceso opera en forma segura TODO EL TIEMPO. ¿Si es difícil el automatizarlo como vamos a esperar que es más fácil para el operador? ¿Cómo se puede esperar que el operador vaya a tomar en forma correcta una decisión compleja, complicada, en el medio de un inestable arranque de planta y bajo presión? De hecho, la misma falta de similitud entre procesos es una razón poderosa para estudiar el arranque del proceso por adelantado asegurándose que las protecciones están activas en todo momento. Finalmente, existen similitudes en estrategias de control para diferentes procesos. Más adelante mostraremos como lidiar con estas en forma consistente.
  • No hay similitud entre las transiciones y las operaciones estables. A pesar de ser un hecho el que la mayoría del tiempo los procesos continuos están en estado estable, los momentos más peligrosos son aquellos de transición, donde las variables son inestables. Es entonces cuando las mismas cambian Constantemente y a una velocidad para la cual el SBCP no está diseñado para manejar. Por ejemplo, el ajuste de los lazos de control en el controlador no es adecuado durante estos periodos. En otras palabras, como es “difícil” el crear permisivos en un SIS, para manejar las transiciones, las dejamos en manos de un operador, a menos que existen estrictos estándares prescriptivos que nos fuercen a automatizar las secuencias de transición, como se menciona en el punto anterior. (Tal es el caso de BMS, y la NFPA 85 y 88). Por otra parte, si hacemos nuestro trabajo correctamente, el tiempo empleado en escribir un manual de operaciones y entrenar los operadores en el manejo de complejas transiciones; podríamos muy bien gastarlo en diseñar SIS que pudieran manejar las rutinas de dichas transiciones, simplificando los procedimientos y el entrenamiento de los operadores. Es por otro lado evidente que una apropiada ingeniería de un SIS es mucho más confiable que el desempeño de personal altamente estresado. Más adelante mostraremos como el uso de tecnología de programación avanzada (de alto nivel), es posible simplificar dichos diseños así como verificarlos)-validarlos.
  • Las transiciones en un proceso son afectadas mucho más por subjetividad operacional y procedimientos que cuando el proceso está en estado estable. Aquí otra vez permitimos que la “Dificultad” sea una razón para renunciar a operar en forma segura. En la realidad, el mismo nivel de información operacional es requerido para escribir los procedimientos necesarios para una rutina de transición (ejemplo arranque de una planta), que para desarrollar la lógica de automatización de un SIS. Los ingenieros se encuentran con dos barreras al tratar de obtener información operacional apropiada: Primero, la secuencia o pasos a seguir en el proyecto. Es realmente difícil obtener información de operaciones en la etapa del diseño de la lógica (software), y es mucho más fácil obtener esa información a la hora de escribir los procedimientos en un manual. Sin embrago, el personal de Operaciones debe de estar envuelto a todo lo largo del ciclo de vida del proyecto. En segundo término, la falta de un lenguaje común o herramientas comunes de comunicación entre los diferentes equipos de trabajo. (Operadores e ingenieros de programación). Definitivamente no es fácil el traducir las necesidades de operaciones en un código de lógica que sea usable en el SIS.
  • Debido a que las transiciones son secuenciales y dinámicas, el temporizado de las etapas del proceso y los enclavamientos es crítico. El comportamiento dinámico del proceso durante las transiciones es la razón de fondo por la cual el proceso debe de ser automatizado. Se requiere de una robusta simulación de las rutinas con la participación de todos los equipos y disciplinas de trabajo para poder ser verificada y validada. Más aun, la idea de dejar todo en manos de un procedimiento escrito a seguir por un grupo de seres humanos, destruye la fiabilidad y auditabilidad de la capa de protección como tal. (Aunque el escrito sea auditable, su aplicación no lo es). En pocas palabras, como la simulación con un manual de procedimientos no es posible, la automatización con herramientas adecuadas de simulación es una mejor respuesta.

REQUISITOS DE SECUENCIACIÓN

Para definir y automatizar adecuadamente secuencias permisivas, se requieren dos cosas:

  • Conocimiento completo y profundo del proceso y su operación
  • Un juego de herramientas que manejen lógica dinámica de seguridad funcional.

CONOCIMIENTO OPERACIONAL DE LAS SECUENCIAS EN EL PROYECTO

Tradicionalmente, en el ciclo de vida de la seguridad funcional de un SIS, Operaciones participa temprano en el proceso de análisis de peligros (PHA-Process Hazard Analysis), y también durante la validación del mismo en aquellas actividades de revisión, para asegurar la capacidad funcional de los diseños. Finalmente, la unidad es completamente entregada a operaciones para el arranque de la misma. Por tanto el grueso de los datos es de un proceso que se encuentra en estado estable.

Para poder automatizar las FIS durante los estados transitorios, se requiere también de información crítica la cual debe de ser provista por quienes conocen el proceso: Operaciones. Esta información debe de ser parte de la información que tradicionalmente se provee puesto que es necesaria durante el diseño de la lógica de ejecución.

Esto representa dos desafíos. Primero que nada es muy difícil obtener la cooperación de Operaciones en forma regular, debido a limitaciones de tiempo. En segundo término los equipos de programación y operación tienen formaciones diferentes y utilizan lenguajes diferentes, haciendo difícil la comunicación efectiva y necesaria para desarrollar las necesidades reales del diseño del programa. Cualquiera que haya estado en una junta de revisión de un programa con operarios simplemente armado con un montón de diagramas de lógica de contactos entiende el problema muy bien.

Sin embargo si realmente nos proponemos mantener las protecciones intactas durante las transiciones en el proceso (como el arranque de planta), es esencial el entender el proceso, qué operaciones va a seguir, así como qué reacciones reales y prácticas se pueden esperar de la unidad. Si las protecciones no son implementadas en forma razonable, es muy posible que sean “bloqueadas” (Bypassed) en la realidad.

Así, una de las primeras decisiones a tomar, es seleccionar un lenguaje de comunicación común entre el personal de operaciones y los diseñadores del sistema.  La forma tradicional de visualizar la lógica de parada de un SIS ha sido con la ayuda de una Matriz Causa-Efecto (MCE).

La MCE es una herramienta originalmente derivada de los gráficos de seguridad (Safety Charts) plasmada en la API RP 14C para aplicaciones en plataformas costa afuera, y es usualmente utilizada en la documentación de los requerimientos específicos de seguridad (Safety Requirement Specifications) y la asignación de FIS a los mismos3.

En la MCE, una serie de desviaciones o anomalías en el proceso son listadas en columna en el eje izquierdo del diagrama, mientras que en una serie de reacciones del proceso se lista en la línea superior de la misma. Las intersecciones entre líneas y columnas determinan la relación entre las anomalías o causas y las reacciones o efectos4.

La MCE se ha convertido en una herramienta muy popular entre los profesionales que se dedican a la seguridad funcional de procesos debido a que es un método sencillo de llenar el vacío comunicacional entre los equipos multidisciplinarios de diseño de SIS. Este diagrama es una forma muy sencilla de entender la lógica implementada en el SIS así como la operación del proceso. Una vez que se esté de acuerdo con la relación entre las causas y los efectos, el sistema puede ser programado (programa de seguridad) con facilidad.

Sin embargo existe una limitación mayor en este tipo de diagramas. Se trata de la habilidad de los mismos para manejar las lógicas de seguridad dinámicas encontradas durante procesos en transición. Las secuenciaciones de permisivos son difíciles de representar puesto que la misma ha sido diseñada para relacionar causas y efectos por medio de simples intersecciones (luces que indican qué causas y qué efectos están activos como se muestra en la figura 2). Se necesitan de más opciones a la hora de definir las intersecciones, no solo para hacer posible la aplicación de lógica dinámica, sino para poder generar completos y entendibles reportes de validación.

HERRAMIENTAS PARA EL DESARROLLO DE LÓGICA DINÁMICA

Existen tres características primordiales en una herramienta de configuración para poder manejar cambios en la lógica. Estas son:

  • Posibilidad de forzar las Salidas (Overrides)
    • Overrides de control como función de las variables de proceso (causas) –
    • Puntos de disparo temporizados (dependencia en el tiempo).
  • Puntos de disparo Variables
    • Más completa relación entre causas y efectos
  • Dependencia en el tiempo
    • Definición de etapas o pasos a seguir
    • Limitante de los Overrides
    • Control de la duración de cada paso o etapa (para demorar o prolongar)

DEPENDENCIA EN EL TIEMPO

En un ambiente MCE, la relación puede tomar tres formas: (figura 3).

Para entender la dependencia de una causa con respecto al tiempo, consideremos el ejemplo de un horno y el proceso de purga del mismo antes de encender el piloto. Si la tasa de circulación de aire (caudal) es constante, entonces la manera de asegurarse que la purga ha sido realizada completamente, es el esperar suficiente tiempo para asegurarse el suficiente volumen de aire de barrido en el hogar del horno.

En este caso la variable es el tiempo y una demora “Post-Disparo” nos aseguraría que la causa está activa durante suficiente tiempo para completar la purga, restringiendo la activación de la siguiente etapa. Se puede considerar entonces tres tipos de temporizado (Figura 3):

  • Función sin temporizado
    • Aquí se observa como operaria la causa sin temporizado
  • Primer tipo: Demora PRE-Disparo o “Demora ON”
    • El efecto se activa un TIEMPO después de que la causa está activa
  • Segundo tipo: Demora POST-Disparo o “Demora OFF”
    • El efecto se desactiva un TIEMPO después de que la causa se desactiva
  • Tercer tipo: Causa Temporizada o “Demora Temporizada”
    • La causa está activa durante un determinado TIEMPO, luego se desactiva independientemente de su estado real.

PUNTOS DE DISPARO TEMPORIZADOS

Purga en aplicaciones de BMS es un buen ejemplo de puntos de disparo variables. La purga es ejecutada a un determinado caudal de aire, el cual es por lo general mayor al requerido para obtener una combustión optima (Tasa Aire-Combustible), Por tanto, en este caso (diseño especifico del horno y sus quemadores) el caudal de aire debe de ser disminuido antes de encender el piloto, pero sin abortar la secuencia de encendido. Esto se logra fácilmente definiendo selectivamente la relación (intersecciones) entre los diferentes puntos de disparo (Causas) en una misma variable y la reacción del proceso (Efecto). Esto se logra si definimos básicamente cinco tipos de intersecciones: Normal o tipo “N”, Normal con posibilidad de hace un Override o tipo “V”, Con memoria (Latch) o tipo “S”, Con memoria y posibilidad de hacer un Override o tipo “R”, de votación o del tipo “XooN” (ver más adelante).

OVERRIDES O SALIDAS FORZADAS DE CONTROL

Lógicas Dinámicas requieren que los efectos puedan ser forzados aunque se encuentren bloqueados por alguna causa. Por ejemplo: En un Horno es necesario dispararlo si perdemos la llama del quemador. Por tanto procedemos a bloquear el paso de combustible a los quemadores (Ejemplo: Un quemador de gas tiene dos válvulas de bloqueo que se deben cerrar y una de purga que se debe abrir). Sin embargo durante el arranque del horno no hay llamada. En el quemador y sin embargo debemos abrir (forzar o Override) el paso de gas para poder encenderlo. Adicionalmente, la apertura del paso de gas no puede realizarse sino hasta que haya causas que se encuentren desactivadas, como por ejemplo que haya llama en el piloto.

Intersecciones tales como “Overrides-Reseteables” nos permiten forzar efectos independientemente de las causas. Estas salidas forzadas deben de tener también limitaciones de tiempo y solo pueden actuar si alguna otra causa no está evitándolo con una intersección normal o del tipo “N”. Esto permite fácilmente condicionar la secuencia de ocurrencia de los permisivos al tener que desactivarse primero todas las intersecciones del tipo “N” antes de poder forzar una salida con intersecciones del tipo “V” o “R”.

En el ejemplo anterior, La FIS de las válvulas del quemador tienen una intersección del tipo “R” con respecto a la causa de llama en el Quemador y por tanto puede ser forzada, pero también tiene una intersección del tipo “N” con respecto a la causa de llama en el piloto. Por tanto la única manera de poder forzar las válvulas del quemador es que exista llama en el piloto, para que la causa con intersección “N” desaparezca, quedando solo la intersección “R”.

En algunos casos, la secuencia de encendido del horno puede incluir el apagar la llama del piloto una vez que el quemador esta prendido, agregando complejidad a la lógica. Esto es fácilmente manejable utilizando la estrategia de votación de manera que el apagado secuencial del piloto no afecte el proceso. Nótese que en este caso se requiere de una demora en el apagado secuencial para agregar el factor de estabilidad a la transición (demora POST-Disparo).

Finalmente la máxima duración del forzamiento de una salida es un factor muy importante a tomar en cuenta. Un Override no puede durar indefinidamente (que es, de paso, la anomalía más común encontrada cuando el sistema se inhibe manualmente) Para referirnos al ejemplo anterior, un operario no puede purgar un horno hoy, y encenderlo la semana entrante.

El tiempo máximo en el cual los quemadores deben de ser encendidos después de una purga debe de ser calculado minuciosamente durante la fase de ingeniería.

UNA MATRIZ CAUSA EFECTO DINÁMICA

Puede entonces concluirse que para que una Matriz Causa-Efecto cumpla en forma eficiente con las funciones de configurar, documentar, validar y verificar un SIS, tanto cuando el proceso está en estado estable como cuando es transitorio, siguiendo el ciclo de vida de seguridad funcional de acuerdo a la S84, debería tener las siguientes características:

  • Indicar que causas y efectos están activos, independientemente de las intersecciones. (Por ejemplo mediante el uso de colores en sus columnas y líneas – Rojo: Activo; Blanco: Inactivo; Verde: Re-armado; etc.)
  • Posibilidad de qué demoras y prolongación de las actividades de las causas sean configurables y claramente indicadas en la matriz (como se explica en la sección: “Dependencia en el Tiempo”)
  • Posibilidad de definir diferentes tipos de relaciones entre causa s y efectos (intersecciones), incluyendo independencia para forzar, enclavar con memoria o formular votaciones complejas para adaptarse a diferentes arquitectura s.
    • N: Normal (El efecto estará activo siempre que la causa este activa)
    • S: Con Memoria (La causa dispara el efecto, el cual se mantiene hasta ser rearmado. (Re-set))
    • V: Con Override (Efecto puede ser forzado independientemente de la causa)
    • R: Con Override y Memoria (combinación de V y S)
  • Capacidad de limitar el tiempo de un Override y de retroalimentar el estado de un efecto a una causa.
  • Capacidad de simular transiciones dinámicas fuera de línea para verificar y validar.

CONCLUSIONES Y RECOMENDACIONES

La planificación de las secuencias de arranque de plantas y equipos es tan complejo y complicado de explicar en un manual de operaciones como lo es en una lógica secuencial, sea cual fuere la herramienta de programación. Los arranques de planta deben de ser automatizados tanto como sea posible para asegurarse la operación en condiciones que no comprometan el SIL originalmente diseñado.

Esto no solo es recomendable sino factible, como lo demuestran estándares más prescriptivos como la NFPA 85 y 86 en aplicaciones de supervisión de quemadores tanto para calderas como para hornos respectivamente.

Lo que básicamente proponemos en este ensayo, es que los diseñadores deberían aplicar los conceptos utilizados y aprendidos en este tipo de aplicaciones de quemadores, y extrapolarlos a otros procesos, puesto que es posible y beneficioso.

Los SIS modernos cuentan con herramientas que permiten automatizar de forma relativamente sencilla las secuencias de arranque y así mantener el proceso protegido en todo momento. Incluso existe un beneficio adicional, ya que estas mismas herramientas pueden generar toda la documentación necesaria para verificar y validar no solo el sistema en condiciones estables, sino además en estados cambiantes como son los arranques.

Algunas de estas herramientas ofrecen lenguajes “amistosos” al personal de operaciones, tales como matriz causa-efecto o árboles de fallo etc. Pero aun haciéndolo con lógica de contactos, la secuencia es posible de programar. Los estándares generales (tales como la ANSI/ ISA 84.00.01 ó lEC 61511 Mod.), aunque hacen mención al mantenimiento de la integridad de la FIS durante todo el ciclo de vida, no tratan el tema con profundidad. Por tanto nos atrevemos a sugerir la generación de anexos, reportes técnicos, prácticas recomendadas o ejemplos sobre el tratamiento sobre arranques, paradas secuenciales y transiciones de proceso.

El mantener un SIS activo en todo momento no solo es buena idea, sino debería ser recomendado claramente en todos los estándares dedicados al tema.

REFERENCIAS

  • IEC 61508, Functional Safety of Electrical / Electronic /Programmable Safetyrelated Systems, Part 1-7, Geneva: International Electrotechnical Commission, 1998.
  • IEC 61511, Functional Safety: Safety Instrumented Systems for the Process Industry Sector, Parts 1-3, Geneva: International Electrotechnical Commission, 2003.
  • ANSI/ISA S84.00.01-2004, Application of Safety Instrumented Systems for the Process Industries, The Instrumentation, Systems, and Automation Society, Research Triangle Park, NC, 2004.
  • Goble, W. M., Evaluating System Safety and Reliability – Techniques and Applications, NC: Raleigh, ISA 1997.
  • Functional Safety Engineering I&II – Exida LLC 2001 – 2004.
  • Gable, W.M., Control Systems Safety Evaluation & Reliability, Research Triangle Park, NC – ISA 1998.
  • Simatic Safety Matriz V 6.1 Help Manual, Copyrights 1995-2004, Siemens AG.
  • Simatic PCS 7 User Manual
0
Compartir:

Dejar un comentario

This site uses Akismet to reduce spam. Learn how your comment data is processed.