PLC de seguridad

Si hablamos exclusivamente de sistemas programables electrónicos (PES) también conocidos como PLC’s de seguridad todos los requerimientos del PES a utilizar en el sistema de seguridad deben estar especificados en las especificaciones de los requisitos de seguridad (SRS). Como requerimientos básicos contemplamos los siguientes:

− Por lo general una empresa ha de elegir un SPLC aprobado por un organismo certificado (TÜV, FM), de forma que cubra hardware, firmware, software de ingeniería y utilidades de comunicación.

− Las funciones automáticas de diagnósticos deben poder ser realizadas por el programa de aplicación, aunque ya disponga de un alto grado de diagnósticos.

− El estado seguro de un SPLC y de los elementos de campo conectados a él debe ser desenergizado o bajo (0).

− Las señales implementadas serán, si es posible, analógicas para facilitar los diagnósticos.

− La conexión de elementos de campo redundantes al SPLC se realizará en tarjetas de entrada o salida diferentes para aumentar disponibilidad y seguridad y evitar fallos de causa común. Estas señales redundantes deben ser comparadas por discrepancia en la aplicación software del SPLC. Los requerimientos para la conexión física de estos elementos al SPLC deben estar en el manual del fabricante.

A la hora de configurar adecuadamente el SPLC se debe tener cuidado en asegurar que todos los parámetros del sistema están configurados dependiendo de cada aplicación específica de seguridad. Se dará una atención especial a:

− El nivel SIL de la SIF.

− Tiempo de ciclo máximo.

− Arquitectura del sistema.

− Tiempo de respuesta.

144

− Configuraciones I/O1 _{y conexiones.}

− Acceso limitado de comunicación externa (p. ej. con el BPCS).

− Reacción de las I/O y los sistemas de fallo.

− Cualquier requerimiento definido en el documento de aprobación del certificado de seguridad (expedido por TÜV o FM) que acompaña al SPLC o PES.

7.5.6.1 Software de Aplicación

La norma IEC 61511 describe 3 tipos de software: aplicación, de servicios, y embebido. El software de aplicación es el que el usuario del sistema escribe y descarga al controlador, es la lógica de seguridad. El software de servicios se utiliza para desarrollar y verificar el programa de aplicación. Software embebido es suministrado como parte del sistema programable, es el firmware. Los dos últimos están regulados para aplicaciones de seguridad por la IEC 61508, los cuales son explícitamente indicados en el certificado de cumplimiento para aplicaciones de seguridad. En el caso del primero, que es el software de aplicación tiene la flexibilidad de desarrollar las SIF definidas por la especificación de los requerimientos de seguridad (SRS) lo cual debe cumplir con un ciclo de vida de seguridad para el software, que está totalmente regulado por la IEC 61511 y la ANSI/ISA-84.00.01- 2004. Este ciclo de vida toma como base la información de las SRS del SIS y la arquitectura de los mismos previamente aprobados junto con las características propias del sistema.

Asimismo la norma IEC 61511 contempla tres tipos de lenguaje software: fixed program languages (FPL), limited variability languages (LVL), full variability languages (FVL). FPL el usuario sólo puede ajustar ciertos parámetros como el rango de un transmisor, la lógica está fijada. LVL contiene funciones de librería predefinida de funciones predesarrolladas y testeadas, incluyen lógicas de escalera, lógica secuencial, función de diagramas de bloques. Este tipo de lenguaje permite al usuario combinar las diferentes funciones para configurar o programar la aplicación lógica requerida. FVL son lenguajes mucho más complejos y permiten un mayor rango de funcionalidad, Pascal y C son dos ejemplos. Este último está diseñado para ser comprensible por programadores.

Actualmente muchos software de programación para la electrónica programable (PE) de los Sistemas Instrumentados de Seguridad emplean La Matriz de Causa Efecto para configurarlos (un ejemplo es SIMATIC Safety Matrix de SIEMENS) y que es considerada como una herramienta de configuración, dado que funcionalmente es la representación gráfica de la matriz causa efecto y está basada y crea internamente bloques funcionales o alguna representación en lenguajes LVL para desarrollar las distintas funciones de seguridad de cada función instrumentada de seguridad que se indica en las propias especificaciones de requerimientos de seguridad del SIS.

El estándar IEC 61511 se limita a tratar el desarrollo del software de aplicación usando los lenguajes FPL o LVL. La mayoría de compañías recomiendan el uso de lenguajes tipo LVL.

Un software de aplicación para programación de la lógica de seguridad ha de ser desarrollado de tal forma que logre:

− Modularidad y funcionalidad.

Sistema Insrumentado de Seguridad Sistemas Instrumentados de Seguridad

145

− Facilidad para probar la funcionalidad, incluyendo características de tolerancia a fallos.

− Posibilidad de realizar modificaciones seguras.

− Posibilidad de añadir comentarios y nombres comprensibles a las variables (tags).

− El software debe ser fácilmente legible a través de la pantalla y también a través de la documentación impresa.

− El diseño de cada módulo de aplicación ha de ser robusto, ha de chequear los datos de las variables. Si existe un error en alguna de las variables ha de ser capaz de reconocerlo, reaccionar y corregirlo (incluyendo detección de fallo de la instrumentación de campo, como fuera de rango, señales “pegadas”, etc.).

− En sistemas integrados con software comunes (ej. DeltaV SIS y DeltaV de EMERSON o SIMATIC PCS7 y SIMATIC S7-400FH de SIEMENS) que utilizan un software de aplicación equivalente para seguridad y para control, los módulos programados de seguridad estarán separados de los de control y estarán etiquetados como módulos relativos a la seguridad.

Cada fabricante de SPLC certificados para seguridad incorporan su lenguaje de programación, su software de aplicación, junto con su ciclo de vida y cumpliendo en gran medida con todos los requisitos aquí mencionados.

Una de las ventajas de utilizar un sistema programable es la capacidad para probar la lógica. Podemos realizar simulaciones con el SPLC fuera de línea. La mayoría de los fabricantes entregan con sus equipos un programa de simulación que permite probar la aplicación durante su desarrollo y una vez desarrollado.

Una vez se ha realizado la programación y previo a la conexión de los elementos de campo se ha de realizar un test del software para comprobar la funcionalidad lógica y la interface con el operador del SPLC. Siempre se ha de testear el programa antes de su instalación definitiva en planta. Este test del software se realizará durante las pruebas FAT (Test de Aprobación en Fábrica) (Ver capítulo 7.7 Pruebas de aceptación de fábrica (FAT, Factory Acceptance Test)).

7.5.6.2 Documentación En general:

− Especificación de los requisitos de seguridad (SRS) basados en el análisis de riesgos y peligros.

Hardware:

− Diagramas de lazo y cableado.

− Descripción de la interface y diagramas.

− Puntos de ajuste de parámetros del sistema.

− Documentación certificada de aprobación del SPLC y sus componentes Programa de aplicación:

− Descripción del programa de aplicación.

146

− Lógica programada.

− Lista de variables, constantes, …

− Identificación de las funciones de no-seguridad.

− Copia del programa de aplicación, escrita y guardada electrónicamente. Pruebas:

− Pruebas realizadas y resultados.

− Persona/s que realizan la prueba y persona que lo aprueba.

− Fecha de la prueba.

7.5.6.3 Operación, mantenimiento y modificación

El fabricante del SPLC indica en su manual de seguridad el ciclo de vida del equipo y el mantenimiento preventivo que debe realizarse para asegurar su correcto funcionamiento como:

− Inspección periódica del armario/cabina donde se encuentra el SPLC para inspección visual y eliminación de polvo.

− Inspección periódica de la refrigeración del armario.

− Cambio de baterías del SPLC, según especificación del fabricante.

− Mantenimiento del UPS de la planta, incluyendo baterías.

Realización de Back up’s después de cada modificación del software del SPLC y como máximo anualmente a fin de tener siempre la última versión del programa instalado, que nos asegure una rápida configuración del sistema. (Ejemplo ANEXO Q: Protección de la información).

− Etc.

Las tarjetas I/O y controladores (CPU’s) que estén en fallo o contengan algún elemento en fallo deberán ser cambiados inmediatamente. Si se trata de elementos redundantes se podrá hacer en línea, teniendo en cuenta el tiempo límite programado que puede un sistema estar en un escenario de fallo antes de llevar el sistema a paro.

Se han de realizar test de funcionalidad del SPLC y de las funciones de seguridad (ver capítulo 7.9.2 Pruebas funcionales e inspección (Proof Testing)) y se han de leer regularmente la lista de errores y eventos que recopila el SPLC, en una herramienta que se llama SOE (secuencia de eventos).

El software de aplicación debe estar protegido mediante passwords para evitar cambios por personal no autorizado. El operador de planta no debe tener acceso al sistema de seguridad ni posibilidad de cambio en el programa de aplicación. (Ejemplo ANEXO Q: Protección de la información).

Todos los cambios realizados deben estar documentados y aprobados.

En sistemas de seguridad, realizar una modificación del programa, manipular una tarjeta del sistema, realizar un cambio de cualquier tipo implica una situación peligrosa, por lo que sólo personal autorizado podrá acceder a la aplicación software, a los parámetros del sistema y al sistema hardware.

Sistema Insrumentado de Seguridad Sistemas Instrumentados de Seguridad

147

Cuando se deba hacer una actualización del firmware para actualizar versiones del sistema, esta se hará con la planta parada y por personal especialista en el sistema, a ser posible personal de mantenimiento e ingeniería del fabricante.

Es una buena práctica el realizar un contrato de mantenimiento con el fabricante del equipo de tal forma que el cliente, en este caso la empresa propietaria del SPLC se asegure principalmente:

− De que cualquier intervención es su equipo de seguridad lo hará personal cualificado y certificado.

− Estar informado de posibles eventos e incidentes que puedan suceder en equipos similares en otras plantas y que pudiesen reproducirse en su sistema.

− Estar informado del estado del SPLC frente a su ciclo de vida.

− Guardar la última versión del programa instalado.

Bibliografía y referencias:

[1] Seminario: PAS Process Safety Seminar. Luis Garcia (CFSE). Automation and Drives, SIEMENS. Tarragona, abril 2008.

[2] IEC 61511 Functional Safety: Safety Instrumented Systems for the process industry sector, Parts 1-3, IEC (International Electrotechnical Comission). 2003

[3] Catálogo DELTA V SIS for Process Safety Systems. Published by EMERSON.