ca2005 a2 automatizacion del ciclo de vida de un pes · causas de varios accidentes industriales...

Sección Española

Presented at ISA Safety Symposium, Madrid – Spain - June, 2005

Automatización del Ciclo de Vida de un SIS, para cumplir con los requerimientos de la IEC 61511 y/o

ANSI/ISA 84.00.01. Herramienta de automatización

L. M. Garcia. CFSE – GPSI Group Siemens Energy & Automation, Sumneytown Pike, Spring House, PA 19477 - USA

PALABRAS CLAVES

ANSI / ISA 84.00.01, IEC 61508, IEC 61511, Sistema Instrumentado de Seguridad, Función Instrumentada de Seguridad, Causa y Efecto

RESUMEN

Con la aprobación final de la IEC61511, y la adopción de la misma por el comité de la ISA/ANSI con el número ANSI/ISA 84.00.01 como el estándar a seguir para la seguridad funcional de proceso, muchos operadores en el mundo de las plantas de proceso tendrán que enfrentarse al desafío que representa la tarea de determinar si cumplen o no con los estándares .

Estos estándares básicamente tienen dos fines: El primero es el determinar el ciclo de vida de los Sistemas Instrumentados de Seguridad (SIS) para plantas Industriales de proceso. O sea, una práctica y simple metodología que define los pasos a seguir para garantizar la seguridad integral de la planta. El segundo es el ayudar a coordinar los niveles integrales de seguridad (SIL – Safety Integrity Levels) necesarios para reducir el riesgo natural asociado al proceso a un nivel aceptable a través del uso de los Sistemas de Seguridad.

Lo expuesto, como es de esperar, tiene varias consecuencias “administrativas” para el usuario final: A medida que en el mundo moderno la seguridad funcional “no es más una opción”, se crean varios requerimientos que de ben ser satisfechos y que se delinean en varias cláusulas de dichos estándares.

Sin embargo cabe enfatizar que las plantas de proceso no son entidades estáticas, sino por el contrario a medida que los requerimientos de mercados cada vez más competitivos cambian, también deben de evolucionar los procesos.

Una herramienta que ayuda significativamente a cumplir con esta constante presión de cambio, que obliga a la gestión de la seguridad funcional en forma dinámica sin perder de vista el cumplimiento de los es tándares, es el uso de la matriz causa-efecto como herramienta de ingeniería, como herramienta de configuración, como generador de documentación al día y como herramienta para manejar los cambios dentro de la filosofía (de seguridad) implementada.

Sección Española


1. INTRODUCCIÓN – El Cic lo de v ida

En 1995, El Ejecutivo Británico de Salud y Seguridad (Health and Safety Executive - HSE) publicó un artículo t i tulado “Fuera de control” (Out of Control ) donde se discute el porqué los sistemas fallan y como prever que los mismos fallen. En el mismo se analiza el origen de las causas de varios accidentes industr iales los cuales fueron iniciados por fal las en los equipos de control, creando un importante precedente como lo es la publicación de esta famosa gráfica donde se muest ra donde se produjeron las fallas en el ciclo de vida de los sistemas. (Figura 1 )

En más de una forma, el resultado de este estudio es lo que llevó al desarrollo de “el ciclo de vida” de seguridad funcional , e l cual es definido en subsecuentes estándares internacionales de seguridad funcional como la ISA S84.01 de 1996, la IEC 61508 de 1998, la IEC 61511 del 2003 y la ANSI/ISA S84.00.01 del año 2004.

El Ciclo de Vida de Seguridad Funcional (CVSF) es simplemente una metodología práctica que delinea los pasos necesarios a seguir para alcanzar la seguridad integral de las plantas de proceso, definiendo la secuenciación y documentación de cada fase. En suma, el ciclo de vida ayuda a prevenir las fallas identificadas en el estudio del Ejecutivo Británico de Seguridad y Salud.

La Figura 2 muestra el ciclo de vida de seguridad funcional como se define en la IEC 61511 (o la ANSI/ISA 84.00.01 – 2004). El mismo puede dividirse en tres fases: La fase de análisis (resaltada en color azul claro), la fase de ejecución o realización (resaltada en color verde claro), y la fase de operación (resaltada en color rojo claro). La fase de análisis está enfocada en la determinación y documentación de cuanta seguridad se requiere o necesita. La fase de ejecución está enfocada en el diseño mismo y en la implementación del sistema, así como en la documentación del nivel de seguridad alcanzada con dicho diseño. Finalmente la fase de operación está enfocada en las actividades y documentación necesaria para operar y mantener el sistema al nivel integral de seguridad original.

15% Diseño e Implementación

6% Instalación y Arranque

44% Especificaciones

15% Mantenimiento y Operación

20% Cambios DespuésDe arranque

Figura 1: Origen y Causas de AccidentesFuente: “Out of Control” un compendio de accidentes que envuelve fallas en sistemas de control. Publicado por UK HSE











Figura 1: Origen y Causas de AccidentesFuente: “Out of Control” un compendio de accidentes que envuelve fallas en sistemas de control. Publicado por UK HSE

Sección Española


Las tres fases del CVSF están dir igidas a resolver las causas de los accidentes como los identifica el estudio de UK HSE. En la fase de análisis, el CVSF está enfocado a resolver y evitar el 44% de las fallas debidas a especificaciones inadecuadas. Esto se busca mediante el requerimiento del análisis cuanti tat ivo del r iesgo y técnicas en reducción de riesgo cuyos resultados finales son las “Especificaciones y Requerimientos de Seguridad Funcional”.

La fase de ejecución, está enfocada a disminuir el 21% de los accidentes causados por errores y/o omisiones durante el diseño, la implementación, la instalación y la puesta en servicio. También aquí se señala la necesidad de la verificación documentada de que el diseño alcanza el nivel integral de seguridad funcional definido en la fase de análisis.

Por ultimo, la fase de operación busca disminuir o eliminar el 35% de los accidentes que son causados por incorrecta operación o mal mantenimiento además de cambios realizados después de que el s istema ha sido puesto en servicio. Aquí otra vez, se busca alcanzar este f in a través de procedimientos y documentación obligatoria. La Figura 3 nos i lus t ra es te punto

Análisis de Riesgo y diseño de capas de ProtecciónSub-Cláusula 8

Asignación de funciones de Seguridad a SIS u otros medios de reducir Riesgo

Sub-Cláusula 9

Especificaciones de Requerimientos de Seguridad para el SIS

Sub-Cláusula 10

Diseño y Desarrollo de un SIS

Sub-Cláusula 11

Diseño y Desarrollo de otros medios de

reducir RiesgoSub-Cláusula 9

Instalación, Puesta en Servicio y ValidaciónSub-Cláusula 14

Operación y MantenimientoSub-Cláusula 15

ModificaciónSub-Cláusula 15.4

Retiro de ServicioSub-Cláusula 16

Gerencia y Avaluó de Seguridad Funcional

Sub-Cláusula5

Estructura y Planeamiento del Ciclo de Vida de Seguridad

Sub-Cláusula6.2

Verificación

Sub-Cláusula7, 12.7



Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11











Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11








Sub-Cláusula5


Sub-Cláusula5


Sub-Cláusula6.2


Sub-Cláusula6.2

Verificación


Verificación


Figura 2: Ciclo de Vida de Seguridad - IEC 61511 – ANSI/ISA S84.00.01



Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11








Sub-Cláusula5


Sub-Cláusula6.2

Verificación




Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11











Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11








Sub-Cláusula5

Gerencia y Avalúo de Seguridad Funcional

Sub-Cláusula5


Sub-Cláusula6.2

Estructura y Planeamiento

del Ciclo de Vida de Seguridad

Sub-Cláusula6.2

Verificación


Verificación


Figura 2



Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11








Sub-Cláusula5


Sub-Cláusula6.2

Verificación




Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11











Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11








Sub-Cláusula5


Sub-Cláusula5


Sub-Cláusula6.2


Sub-Cláusula6.2

Verificación


Verificación




Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11








Sub-Cláusula5


Sub-Cláusula6.2

Verificación




Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11


reducir RiesgoSub



Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11








Sub-Cláusula5


Sub-Cláusula6.2

Verificación




Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11











Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11








Sub-Cláusula5

Gerencia y Avalu

-Cláusula 9









Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11








Sub-Cláusula5


Sub-Cláusula5


Sub-Cláusula6.2


Sub-Cláusula6.2

Verificación


Verificación


Figura 2: Ciclo de Vida de Seguridad - IEC 61511 – ANSI/ISA S84.00.01



Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11








Sub-Cláusula5


Sub-Cláusula6.2

Verificación




Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11


reducir RiesgoSub



Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11








Sub-Cláusula5


Sub-Cláusula6.2

Verificación




Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11











Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11








Sub-Cláusula5

Gerencia y Avalú

-Cláusula 9









Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11








Sub-Cláusula5

Gerencia y Avalúo de Seguridad Funcional

Sub-Cláusula5


Sub-Cláusula6.2



Sub-Cláusula6.2

Verificación


Verificación


Figura 2

Sección Española




Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11








Sub-Cláusula5


Sub-Cláusula6.2

Verificación




Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11











Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11








Sub-Cláusula5

Gerencia y Avalú

Figura 3: Misión del Ciclo de Vida de Seguridad Funcional

o de Seguridad Funcional

Sub-Cláusula5


Sub-Cláusula6.2



Sub-Cláusula6.2

Verificación


Verificación




Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11








Sub-Cláusula5


Sub-Cláusula6.2

Verificación




Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11


reducir RiesgoSub



Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11








Sub-Cláusula5


Sub-Cláusula6.2

Verificación




Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11











Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11








Sub-Cláusula5

Gerencia y Avalú

-Cláusula 9









Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11








Sub-Cláusula5

Gerencia y Avalú

Figura 3: Misión del Ciclo de Vida de Seguridad Funcional

o de Seguridad Funcional

Sub-Cláusula5


Sub-Cláusula6.2



Sub-Cláusula6.2

Verificación


Verificación


Sección Española


2. REQUERIMIENTOS ESTÁNDAR

La norma o estándar IEC 61511 se divide en tres partes bajo el t í tulo genérico de: “Seguridad Funcional: Sistemas Instrumentados de Seguridad para el sector de la Industria del Proceso” . Las mismas son:

Parte 1 : Estructura, Definiciones, Sistema, Requerimientos de Hardware y Software – Normativa.

Parte 2 : Guias de aplicación de la IEC 61511-1- Informativa

Parte 3 : Direcciones para la determinación de los Niveles Integrales de Seguridad (SIL – Safety Integrity Levels) - Informativa

En general este estándar i lustra y aborda las actividades del ciclo de vida de seguridad funcional que ayudarán al usuario a alcanzar los requerimientos mínimos definidos. Este enfoque ha sido adoptado para que siempre se use la misma polí t ica racional y consistente. Para facilitar esta tarea, el estándar:

1. Requiere que se haga una evaluacion del peligro y el riesgo envuelto, para identificar los requerimientos de seguridad.

2. Especifica que los requerimientos de seguridad sean asignados al s is tema instrumentado de seguridad.

3. Está enmarcado en un ambiente en el cual puede ser aplicable a todos los métodos para alcanzar seguridad funcional.

4. Detalla ciertas act ividades tales como la gest ión de seguridad funcional , que pueden aplicarse a cualquier método para alcanzar seguridad funcional.

Sección Española


3. CUMPLIMIENTO DEL ESTÁNDAR

De igual manera, el estándar, identifica varias condiciones o cláusulas que deben de ser cumplidas para acreditarse el seguimiento del mismo. Es la intención del comité que suscribe la norma que cada requerimiento indicado (en las cláusulas que van de la 5 a la 19), haya sido sat isfecho de acuerdo al cri terio y por tanto objetivos de cada cláusula.

Cabe a estas alturas resumir dichos requerimientos que, como ya se ha explicado, es necesario seguir para cumplir con la IEC 61511. De esta forma podremos introducir una metodología en seguridad funcional que reduce significativ amente el esfuerzo necesario para cumplir con dichos requerimientos. Veamos entonces las s iguientes cláusulas:

Cláusula 5 – Gestión de la Seguridad Funcional: La norma exige que la política y estrategia para alcanzar Seguridad Funcional, debe estar definida e identificada junto con los medios para evaluar si se ha alcanzado el nivel requerido, y debe ser comunicada dentro de la organización. Cláusula 6 – Requerimientos del Ciclo de Vida de Seguridad Funcional: La norma define cada fase además de establecer los requerimientos de las actividades técnicas del ciclo de vida de Seguridad Funcional, de forma que puedan organizarse para asegurar que existe o está siendo desarrollada una planificación adecuada que permita alcanzar los requerimientos de seguridad funcional.

Cláusula 8 – Peligros en el Proceso y Análisis de Riesgo: La norma determina el peligro o eventos pel igrosos del proceso y los equipos asociados al mismo que pueden provocar un evento pel igroso.

Cláusula 9 – Asignación de Funciones de Seguridad a las capas de Protección: La norma asigna funciones de Seguridad a cada capa de protección y determina su nivel integral de seguridad asociado a dicha función.

Cláusula 10 – Especificaciones de los Requerimientos de Seguridad Funcional de un SIS: La norma especifica los requerimientos de la o las Función o Funciones Instrumentada(s) de Seguridad Funcional (FISF). Como veremos, la Matriz Causa-Efecto (MCE) ayudará a definir las FISF. Los requerimientos de seguridad funcional serán derivados de las asignaciones de FISF y de los requerimientos identificados durante la planificación de la seguridad funcional.

Cláusula 11 – Diseño e Ingeniería de un SIS :

Objetivo: El objetivo de los requerimientos de esta cláusula es el diseñar uno o varios SIS para proveer las FISF y alcanzar el nivel integral de seguridad (SIL) especificado. 11.2.1 La norma indica que el diseño de un SIS debe de estar en concordancia con los requerimientos y especificaciones de seguridad funcional del SIS, teniendo en cuenta todos lo requerido en esta cláusula.

Sección Española


4. INTRODUCCIÓN A LA MATRIZ CAUSA-EFECTO

La lógica se define como la ciencia del razonamiento correcto. Por tanto es la ciencia que conecta un resultado a través del procesamiento de causas y efectos. En otras palabras, si un problema es analizado en forma lógica, el mismo producirá una solución ó confirmará que su resolución no es posible. Examinando todas las eventualidades con respecto a las causas y los efectos existentes, suele encontrarse siempre una solución. En el contexto de este trabajo, la metodología de MCE se utiliza para definir cómo y cuándo deben ejecutarse la acciones en un sistema de seguridad. Como tal, esta metodología envuelve la organización de eventos en el proceso en dos categorías: Causas y Efectos. Ambas categorías son luego interrelacionadas con interconexiones lógicas. Tales interconexiones, llamadas intersecciones, indican entonces qué efecto resultará o se activará por qué causa o con la activación de qué causa. De todos los datos, esta lógica puede ser entonces extrapolada para crear un programa que ejecute reacciones de un sistema para contener, evitar o prevenir eventos antes de que puedan causar daños al proceso. Más aún, este procedimiento puede ser muy beneficioso para documentar la filosofía de seguridad desarrollada durante el proceso de análisis de riesgo y de peligro, conocido comúnmente en algunas industrias (las petroleras), como HAZOP (Hazardous Operation Analysis). Existen entonces tres campos de información en una MCE: Las Causas, los Efectos y las Intersecciones. En la MCE, las causas ocupan las filas horizontales y los efectos las columnas verticales. Una intersección es la celda que es común a una causa (fila) y un efecto (columna). Cada campo indica:

• Causas - Este campo refleja una desviación o aberración en el proceso. Cuando una variable específica (causa) alcanza ciertas condiciones definidas por el usuario, la misma se activa.

Ejemplo: Variable: Presión Máxima / Identificación: (TAG): PT001 / Valor: 150 PSIG – Al registrar el sensor PT001 que la presión ha alcanzado un valor igual o mayor a150 PSIG, la causa se activa

• Efectos – Este campo refleja la acción tomada en el proceso. Cuando un efecto está activo significa que la salida al proceso ha tomado su valor de “Falla-Segura”.

Ejemplo: Elemento: Válvula de corte / Identificación: VC020 / Acción: CERRAR

• Intersecciones – Este campo determina cómo el efecto responde a la causa. Si la intersección está vacía, el efecto no responde a la causa. Si por el contrario, la intersección está configurada, una causa activa disparará el efecto asociado y dicho efecto se activará.

La MCE ha sido utilizada para diseñar SIS desde hace mucho tiempo, como una herramienta gráfica para analizar y documentar las aberraciones de proceso que conducen a s i tuaciones peligrosas, y las acciones que tales anomalías deben disparar o iniciar. Un ejemplo de este documento se muestra en la Figura 4 .

Sección Española


En las “Prácticas Recomendadas”, distinguidas con el número API 14C, del Instituto Americano del Petróleo (The American Petroleum Institute-API), se define el uso de lo que describe como “Tablas de Evaluación para Análisis de Funciones de Seguridad” o SAFE (Safety Analysis Function Evaluation Chart ), que es una forma de MCE aplicada al diseño de Sistemas de Parada de Emergencia (Emergency Shut Down – ESD) en plataformas costa afuera.

Debido a que la MCE es una directa y simple representación gráfica de la operación del sistema, permite que todo el personal envuelto en el CVSF (ingenieros de proceso, ingenieros de mantenimiento, instrumentistas, evaluadores de riesgo, operadores etc.) pueda comunicarse en un lenguaje común. De esta manera encontramos que la MCE ha sido durante años una herramienta importante en el análisis del CVSF. Sin embargo, su eficiencia ha sido siempre limitada debido a que los SIS han sido programados utilizando lenguajes diferentes (ejemplo: Lógica Escalera, Diagramas Boléanos, etc.).

En la actualidad se dispone ya de herramientas de automatización capaces de implementar el método descrito anteriormente que pueden util izarse, no sólo como herramienta de análisis, sino también como herramienta para programar, para operar y para mantener, acometiendo todas las fases del CVSF, incluyendo la documentación y la gestión de cambio como veremos a cont inuación.

Figura 4: Matriz Causa-Efecto como Especificación de Requerimientos de Seguridad Funcional

Causas

Efe

ctos

Intersecciones

Figura 4: Matriz Causa-Efecto como Especificación de Requerimientos de Seguridad FuncionalFigura 4: Matriz Causa-Efecto como Especificación de Requerimientos de Seguridad Funcional

CausasCausas

Efe

ctos

Efe

ctos

Intersecciones

Sección Española


5. MÁS DE LA IEC 61511 - ANSI/ISA S84.00.01

Veamos ahora que nos indican las normativas con respecto a la documentación.

Cláusula - 19 Requerimientos de Información:

Para asegurar que se dispone de la información necesaria , (que hay documentos de respaldo al CVSF), de forma que puedan realizarse las evaluaciones, validaciones y avalúos que se requieren, la norma exige que:

19.2.1 Los documentos requeridos por el estándar deben de estar disponibles y al día.

19.2.2 La documentación debe:

- Describir la instalación, sistema o equipo usado.

- Ser precisa

- Ser fácil de entender

- Estar al alc ance de todo el personal implicado en el CVSF

- Tener un formato que permita su continuo mantenimiento y vigencia

19.2.3 Estar ordenada para rápida referencia. Catalogada por partes únicas

19.2.4 Cada documento debe tener descripciones indicando el t ipo de información que contiene.

19.2.5 La documentación debe ser rastreable hasta cada requerimiento de este estandar.

19.2.6 La documentación debe tener un índice indicando su revisión para poder identificar y comparar diferentes versiones.

19.2.7 La estructura del catálogo de la documentación debe de permitir con facilidad el buscar la información requerida e identificar la última versión de cada documento.

19.2.8 Toda documentación debe estar mantenida, revisada periódicamente, corregida, supervisada, aprovada y estar bajo control dentro de un esquema apropiado.

19.2.9 Los documentos siguientes deben incluirse y manterse.

a ) Los resul tados del avalúo de r iesgo, pel igros y presunciones.

b ) Los equipos uti l izados para las FISF, junto a los requerimientos de seguridad funcional.

c ) La organización responsable de mantener la seguridad funcional.

d ) Los procedimientos para alcanzar y mantener la seguridad funcional del SIS

e ) La modificaciones. (Consulte cláusula 17.2.5 – ANSI/ISA S84.00.01 – 2004 Part I)

f) Diseño, implementación, pruebas y validación.

Sección Española


NOTA 1 Para ejemplos de estructuras de documentos, consulte la IEC 61508-1 Anexo A. Para más detalles, consulte la IEC 61506: 1997 "Industrial process measurement and control – Documentation of application software".

NOTA 2 La documentación puede estar disponible en formas diferentes, como por ejemplo: Papel, microfilm, o cualquier medio de recolección y registro de datos.

Sección Española


Figura 5: Simatic Safety Matrix

Como Especificación de Requerimientos de Seguridad Funcional

CAUSAINTERSECCION

EFECTO

Figura 5: Simatic Safety Matrix

Como Especificación de Requerimientos de Seguridad Funcional

CAUSAINTERSECCION

EFECTO

6. SIMATIC® SAFETY MATRIX

Veamos ahora un ejemplo: SIMATIC Safety Matrix (S S M)

SSM es un moderno juego de herramientas basado en la MCE, diseñadas para facilitar la automatización del ciclo de vida de un SIS. Esta novedosa herramienta reduce la configuración, las pruebas funcionales, el diseño y el mantenimiento en un 50% como mínimo, aglutinando en un solo paso lo que tradicionalmente se hace en varias etapas, como lo son la creación de una MCE, la configuración del SIS y las pruebas de funcionamiento.

Más aún, SSM fue desarrollada como herramienta de diseño y como metodología de fácil uso para la variada gama de personal usualmente envuelto en el CVSF (Ingenieros de proceso, operarios y personal de mantenimiento).

En suma, SSM funciona como herramienta de diseño y programación, como herramienta para el operador (interfase Hombre -Máquina para supervisión) y como herramienta de mantenimiento.

7. RELACIÓN ENTRE SSM y CVSF

SSM es tanto una herramienta como un método, y está en ambos sentidos, estrechamente l igada a todos los aspectos del CVSF.

Durante la fase de análisis, SSM funciona principalmente como herramienta para cumplir con los requerimientos de documentación. Mientras que hay varias herramientas en el mercado para hacer análisis de riego, capas de protección y selección y cálculo de nivel SIL, SSM es ideal para documentar las FISF. De hecho la MCE en sí se convierte en la parte más importante de las FISF. (Figura 6a)

Sección Española




Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11



Instalación, Puesta en Servicio y Validaci ónSub-Cláusula 14

Operaci ón y MantenimientoSub-Cláusula 15

Modificaci ónSub-Cláusula 15.4



Sub-Cláusula 5


Sub-Cláusula 6.2

Verificaci ón

Sub-Cláusula 7, 12.7



Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11











Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11








Sub-Cláusula 5


Sub-Cláusula 5


Sub-Cláusula 6.2


Sub-Cláusula 6.2

Verificaci ón


Verificaci ón


Figura 6b - Fase de EjecuciónSSM como herramienta de configuración, puesta en servicio, validación y

documento de soporte



Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11








Sub-Cláusula 5


Sub-Cláusula 6.2

Verificaci ón




Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11











Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11








Sub-Cláusula 5


Sub-Cláusula 5


Sub-Cláusula 6.2


Sub-Cláusula 6.2

Verificaci ón


Verificaci ón


Figura 6b - Fase de EjecuciónSSM como herramienta de configuración, puesta en servicio, validación y

documento de soporte



Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11








Sub-Cláusula 5


Sub-Cláusula 6.2

Verificaci ón




Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11











Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11








Sub-Cláusula 5


Sub-Cláusula 5


Sub-Cláusula 6.2


Sub-Cláusula 6.2

Verificaci ón


Verificaci ón


Figura 6a - Fase de Análisis SSM como herramienta de diseño y documento de soporte de las FISF



Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11








Sub-Cláusula 5


Sub-Cláusula 6.2

Verificaci ón




Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11











Sub-Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11








Sub-Cláusula 5


Sub-Cláusula 5


Sub-Cláusula 6.2


Sub-Cláusula 6.2

Verificaci ón


Verificaci ón


Figura 6a - Fase de Análisis SSM como herramienta de diseño y documento de soporte de las FISF

En la fase de ejecución, SSM juega un papel fundamental ya que permite programar en forma automática el PLC de seguridad a partir de las FISF, o sea de la(s) MCE completa (s). Por ser el proceso automático además de cert if icado, se evitan todos los errores de programación t ípicos en este t ipo de aplicaciones. Usuarios de esta herramienta han reportado ahorros de un 50% en el CVSF, solo debido a esta característica. (Figura 6b)

Sección Española


Análisis de Riesgo y diseño de capas de ProtecciónSub -Cláusula 8

Asignaci ón de funciones de Seguridad a SIS u otros medios de reducir Riesgo

Sub -Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11



Instalaci ón, Puesta en Servicio y ValidaciónSub-Cláusula 14




Gerencia y Avalu óde Seguridad Funcional

Sub-Cláusula 5


Sub-Cláusula 6.2

Verificaci ón




Sub -Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11











Sub -Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11








Sub-Cláusula 5


Sub-Cláusula 5


Sub-Cláusula 6.2


Sub-Cláusula 6.2

Verificaci ón


Verificaci ón


Figura 6c - Fase de OperaciónSSM como herramienta de supervisión, manteamiento documento ideal de

soporte para la gestión de cambio, donde el CVSF es repetido.



Sub -Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11








Sub-Cláusula 5


Sub-Cláusula 6.2

Verificaci ón




Sub -Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11











Sub -Cláusula 9


Sub-Cláusula 10


Sub-Cláusula 11








Sub-Cláusula 5


Sub-Cláusula 5


Sub-Cláusula 6.2


Sub-Cláusula 6.2

Verificaci ón


Verificaci ón


Figura 6c - Fase de OperaciónSSM como herramienta de supervisión, manteamiento documento ideal de

soporte para la gestión de cambio, donde el CVSF es repetido.

La facilidad que ofre ce SSM para la supervisión “en l ínea” junto con el registro de eventos y otras características y usos en mantenimiento, la hacen la herramienta ideal para la puesta en servicio. Aquí otra vez, los usuarios han estado reportando ahorros de hasta un 60% en el t iempo necesario para la puesta en servicio y las pruebas de validación tanto en fábrica como en sit io.

A pesar de ser una herramienta extremadamente valiosa en las dos fases descritas arriba (análisis y ejecución), el verdadero beneficio de utilizar SSM es mucho más aparente en la fase de operación, donde se realiza además el mantenimiento, la resolución de problemas y la gestión de los cambios. (Figura 6c).

SSM Viewer es una interfase gráfica y “en l ínea” que está completamente integrada en la interfase del operador en el sistema de control. El Viewer permite la operación y mantenimiento del personal a cargo, monitorizando la matriz con datos en vivo. Mejor aún, el Viewer t iene incorporado un secuenciador de eventos con indicación de la primera causa. Este secuenciador automáticamente cronometra y estampa la hora y el día en cada evento con resoluciones del orden de los mil isegundos, que deposi ta en un registro de eventos que incluye además todas las actividades realizadas en la matriz. Esta característica es de gran util idad en las operaciones ordinarias del día a día, en el mantenimiento y en las pruebas periódicas que deben de hacerse, porque todo lo que ocurre queda automáticamente registrado y documentado.

Sección Española


8. EL DIAGRAMA DE FLUJO DEL CVSF y DEL SSM

En suma, las figuras 6ª, 6b y 6c muestran los diagramas de flujo de SSM hacia y desde el CVSF como se indica en la IEC61511 – ISA/ANSI 84.00.01.

SSM “Engineering tool” puede documentar una buena porción de los requerimientos de s eguridad siendo una expresión de las FISF, pero con toda la documentación de soporte. Como cualquier otro documento, los archivos de SSM pueden enviarse a miembros del equipo para su revisión y/o aprobación. Una vez aprobadas las matrices (que como se explicó son FISF), basta tres golpes del ratón en la estación de ingeniería para convert ir estas FISF en la base de datos del controlador del PLC de seguridad. Sin errores. Cuando llega la hora de poner el sistema en servicio, SSM “Viewer” y el registro de eventos, t rabajan en conjunto para proveer la visión en t iempo real del proceso y registro automático de todas las actividades. Con el registro se generan informes durante la puesta en servicio, arranque operación o mantenimiento, por ejemplo para documentar que cada causa fue probada.

Finalmente, las modificaciones que se necesiten hacer al sistema durante su ciclo de vida, son fáciles de hacer y administrar con SSM, gracias al programa de gestión de revisiones que incluye en el paquete. Como la MCE son la s mismas FISF, no sólo el programa ha sido modificado y puesto al día, sino las FISF también.

9. CONCLUSIONES

El CVSF, o sea, la base fundamental de los nuevos estándares de seguridad funcional para procesos industr iales, es un proceso muy importante, aunque intensivo en lo referente a ingeniería y documentación.

Varias herramientas en forma de programas han sido desarrolladas para ayudar en este aspecto del ciclo de vida. SIMATIC Safety Matrix es una de ellas, al permitir automatizar casi en su totalidad el CVSF, siendo una herramienta de diseño, programación, configuración, mantenimiento, supervisión, gest ión y generación de documentación de soporte, atando de esta manera todas las fases del proceso.

10. REFERENCIAS

1. IEC 61508, Functional Safety of Electrical/Electronic/Programmable Safety-related Systems, Part 1-7,

Geneva: International Electro technical Commission, 1998.

2. IEC 61511, Functional Safety: Safety Instrumented Systems for the Process Industry Sector, Parts 1-3, Geneva: International Electro technical Commission, 2003.

3. 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.

4. API RP 14C, Recommended Practice for Analysis, Design, Installation, and Testing of Basic Surface Safety Systems for Offshore Production Platforms, American Petroleum Institute, 2001

5. J. Cusimano/C. Fialkowski white paper ”Using cause and effects for compliance” – April 2004/March 2005 Rev 2

6. Goble, W. M., Evaluating Systems Safety and Reliability - Techniques and Applications, NC: Raleigh, ISA 1997.

ca2005 a2 automatizacion del ciclo de vida de un pes · causas de varios accidentes industriales...

Documents