¡No se puede probar el CPU de un SIS…!

Por Luis M. García G.
ISA InTech México,
Edición Julio – Septiembre 2012. Año 11 Número 3.

Es práctica común desde hace mucho tiempo, que cada Función Instrumentada de Seguridad (SIF), sea probada periódicamente para asegurarse que se alcanza un rendimiento o desempeño determinado. La responsabilidad de conducir estas pruebas, tradicionalmente, ha recaído sobre los hombros del usuario con muy poca ayuda o guía por parte de la mayoría de los fabricantes.

El proceso, por otra parte, se convierte en un verdadero desafío cuando el usuario tiene que lidiar con complejos sistemas electrónicos programables (PES)2, también llamados Controladores Lógicos programables (PLC)3 de seguridad.

Para poder revisar un equipo en forma apropiada, uno debe de responder tres preguntas:

  • ¿qué tan frecuentemente necesito revisar y probar, mensualmente, anualmente o cada quinquenio?
  • ¿cuál es el procedimiento para realizar las pruebas e inspecciones?
  • ¿cuánta cobertura, y por ende crédito, se puede reclamar con cada inspección y revisión?

Pruebas periódicas de PLCs comunes para aplicaciones de seguridad funcional han sido siempre bastante importantes debido a su falta de diagnóstico, y aunque de cuestionable practicidad, resultaba mucho mejor que el no hacer nada. Sin embargo los fabricantes de PLCs de seguridad de hoy en día reclaman diagnósticos con coberturas mejores que un 99%, lo que nos lleva a preguntar;

  • ¿qué es lo que el usuario final pretende lograr probando dichos sistemas?
  • ¿será que acaso se pretende cubrir con estas pruebas el 1% remanente?

Para entender esto mejor debemos volver a los primeros principios:

  • ¿para qué se realizan pruebas de inspección en primer término?,
  • ¿qué valor hay en probar e inspeccionar los sistemas?,
  • ¿no es esta la función del diagnóstico?

DEFINICIÓN DE UN SIS Y SUS FIS

La cláusula 3.2.72 (Parte 1 del estándar ANSI/ISA 84 – IEC 61511 Modificada) define un Sistema Instrumentado de Seguridad (SIS) como: un sistema instrumentado usado para implementar una o más Funciones Instrumentadas de Seguridad (SIF, por sus siglas en inglés). Por tanto un SIS se compone de alguna combinación de sensores, procesadores lógicos y elementos finales de control. Su misión es llevar la planta a un estado seguro cuando ciertas pre-determinadas condiciones han sido violadas.

Para ponerlo en forma simple, es un sistema hecho de componentes especiales (Entradas, Salidas y Controlador) que monitorea, procesos específicos; y si por alguna razón cualquiera de las variables monitoreadas viola sus límites de seguridad, el sistema está diseñado para llevar el proceso a un estado seguro pre-determinado.

Lo primero que tal definición implica es que si dicha condición “peligrosa” no se presenta “nunca”; el SIS no va a actuar “NUNCA”. Por tanto el determinar qué tan bien el sistema va a actuar si se requiere que lo haga, es un asunto bastante confuso. Por ejemplo; si el lector tiene un automóvil de diez años de uso:

  • ¿qué tan confiado está el lector que la bolsa de aire se va a abrir si se tiene una colisión?,
  • ¿qué tan confiado puede estar un piloto veterano de cinco años en que el paracaídas que le dieron al ingresar a la fuerza hace cinco años, y que nadie ha probado desde entonces, se va a abrir si lo necesita?,
  • ¿qué tan frecuentemente probaría usted su paracaídas?,
  • ¿cómo lo probaría?,
  • ¿quién lo probaría?

Todas estas son preguntas muy importantes cuando hablamos de sistemas durmientes.

MEDICIÓN DEL RENDIMIENTO DE UN SIS

Cuando hablamos de un sistema “durmiente” no implicamos referirnos a un sistema que “no está haciendo nada”, sino todo lo contrario. Para hacer una analogía de un sistema durmiente, observemos los guardias del palacio de Buckingham. Estos guardias no se mueven, no hablan ni socializan con los visitantes; de hecho no hacen ninguna mueca por lo que no parecen reales, sino más bien muñecos. Sin embargo puede uno estar seguro de que si alguien intenta infiltrar en el palacio sin ser autorizado, estos guardias inmóviles, saltaran sobre el intruso y lo arrestarán.

Un SIS se encuentra inmóvil como los guardias del palacio y sólo ejecutan acciones cuando una condición peligrosa pre-determinada existe. El desafío es entonces el determinar o evaluar el rendimiento del sistema (o qué tan bueno es) debido a que no está actuando. Los estándares de seguridad funcional toman en cuenta este hecho. Por tanto, estos estándares de seguridad funcional están basados en rendimiento o desempeño, y fueron desarrollados por dos razones:

  1. Todos los procesos son distintos, por lo que sería imposible basar un estándar en un proceso determinado.
  2. Los estándares prescriptivos requieren de mucho mantenimiento pues deben mantenerse al día con la tecnología.

Como resultado, se concluyó entonces que se deberían desarrollar estándares basados en desempeño, ayudando entonces a diseñar un método para medir el rendimiento de sistemas durmientes.

CONCLUSIÓN

Manualmente es imposible hacer pruebas funcionales de un sistema complejo tal como un procesador lógico programable, con el fin de obtener crédito en el cálculo de su rendimiento. En el caso de PLC de seguridad, basado en protección por diagnóstico de acuerdo con la IEC 61508, con coberturas por encima del 90% y SFF de más del 99%, todavía es más obvio que realizar tales pruebas funcionales manuales no beneficia absolutamente en NADA.

Sin embargo, quien subscribe ha visto cómo los usuarios finales han batallado para entender el significado de las pruebas funcionales periódicas que algunos fabricantes de PLC de seguridad piden en sus manuales, reclamando por otra parte, que al ser el sistema inspeccionado se obtiene un crédito del 100%.

Inspeccionar periódicamente una Función Instrumentada de Seguridad es una muy buena práctica, pero por otra razón; la evaluación de los instrumentos de campo. Si hay instrumentos tipo A (o Tipo B muy simples con FPL), las pruebas funcionales incrementan el rendimiento, como se muestra en el ejemplo de la válvula. Como las pruebas manuales no pueden sino detectar una fracción mucho más pequeña de fallas que las inspecciones automáticas en un complejo sistema Tipo B, los PLC y otros sistemas complejos basados en Software, utilizados en FIS, deberían garantizar PFDPro sin inspecciones manuales y con una vida útil de 20 años.

Tabla de requerimientos de desempeño en demanda. (lEC 61508)

Al cabo de dicho periodo, el usuario debiera devolver el sistema al fabricante para re-evaluar y re-validar, o simplemente reemplazar el equipo con otro nuevo. Si algún fabricante, a pesar de la contundente evidencia presentada, recomienda el hacer pruebas manuales de su sistema Tipo B para garantizar un SIL (por su tipo de lenguaje, porque es firmware y software FPL, porque el sistema es muy sencillo, porque existe suficiente evidencia que explique todos los modos de falla, etcétera); debería claramente indicar:

  1. ¿Qué tan frecuentemente se debe probar el sistema?
  2. ¿Cómo se deben realizar las pruebas?
  3. ¿Qué porcentaje de diagnóstico se puede reclamar?

Por supuesto que existen aquellos que argumentarán que las pruebas funcionales para cada SIF nos permite el detectar problemas en los programas de aplicación; sin embargo esto es una falacia, ya que si se siguen las recomendaciones del ciclo de vida de seguridad funcional, los problemas previos y póstumos al comisionamiento debieran haber sido detectados durante las pruebas de validación.

GLOSARIO

  1. SIF, por sus siglas en inglés – Safety Instrumented Function.
  2. PES, por sus siglas en inglés – Programmable Electronic Systems
  3. PLC, por sus siglas en inglés – Programmable Logic Controller

ACERCA DEL AUTOR

Luis García es Chartered Engineer, y es miembro del CFSE advisory board, representando a Siemens Energy Inc. Contacto: Ing. Mario Rosas, +52 55 5328 2112, mario.rosas@siemens.com, www.siemens.com.mx.

0

Dejar un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.