S uguur tnttr rro rri o iid od d - aadeca.org · MARZO 26, 2007 Ing. Qco. Roberto E. Varela ©...

323
Ing. Qco. Roberto E. Varela © I I In n nt t tr r ro o od d du u uc c cc c ci i ó ón n na a a l l la a a S S Se e eg g gu u ur r ri i id d da a ad d d F F Fu u un n nc c ci i io o on n na a al l l

Transcript of S uguur tnttr rro rri o iid od d - aadeca.org · MARZO 26, 2007 Ing. Qco. Roberto E. Varela ©...

Ing. Qco. Roberto E. Varela ©

IIIInnnnttttrrrroooodddduuuucccccccciiiióóóónnnn aaaa llllaaaa SSSSeeeegggguuuurrrriiiiddddaaaadddd FFFFuuuunnnncccciiiioooonnnnaaaallll

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Propiedad de la Información

• El material de este curso es de propiedad del instructor y por ninguna circunstancia este material, o parte del mismo, podrá ser reproducido o transmitido en ningún formato, o medio, ya sea mecánico o electrónico. Esto incluye fotocopiado, microfilmado, registro o almacenamiento en computadoras sin el consentimiento previo y por escrito del instructor.

• Por información adicional dirigirse a:

Ing. Roberto E. Varela

Av. Belgrano 1828 - 4 D

C1094AAN Ciudad de Buenos Aires

Tel.: +54 11 4383 – 3223

E-mail: [email protected]

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Notas

• La información contenida en el curso consiste en conceptos fundamentales de Seguridad Funcional y de Sistemas Instrumentados de Seguridad (SIS). Esta información no está diseñada sobre, ni describe, la operación de una instalación específica. Cualquier similitud con la operación de un proceso existente es solamente una mera coincidencia.

• El instructor no asume ninguna responsabilidad por el material del curso mas allá del propósito definido de entrenar a los asistentes en los fundamentos básicos de Seguridad Funcional.

• El material provisto no será utilizado, ya sea en forma parcial o total, para otros cursos de entrenamiento que aquellos dictados por el instructor.

• Las marcas y productos mencionados en las filminas son propiedad de los fabricantes.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

�Temas de Análisis

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Temas de análisis

• Accidentes industriales emblemáticos

• Lecciones aprendidas

• ¿Qué es Seguridad?

• ¿Qué es Seguridad Funcional?

• Gestión de la Seguridad Funcional

• ¿Si en la planta no ha ocurrido un incidente en los últimos 15 años que haya puesto en riesgo la seguridad, es una planta segura?

• ¿Qué es un Sistema Instrumentado de Seguridad – SIS?

• ¿Se dispone de normas, códigos y prácticas recomendadas para el diseño de SIS?

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Temas de análisis

• ¿Cuales son los riesgos dentro de la planta?

• Identificación de Peligros y Análisis de Riesgo

• Técnicas y métodos para el Análisis y Evaluación de Riesgos

• ¿Qué es un nivel de riesgo aceptable?

• Tecnologías disponibles para el diseño de SIS: relés mecánicos, relés estado sólido, sistemas de estado sólido, SEPs...

• ¿Se pueden desempeñar las funciones de seguridad de un SIS en un SBCP (DCS)?

• ¿Cómo afectan las normas vigentes el diseño, instalación y mantenimiento de mi sistema de seguridad?

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Temas de análisis

• ¿Cómo se evalúa un SIS?

• ¿Cómo afectan la disponibilidad y la seguridad de mi SIS los equipos de campo, los sistemas de votación, los diagnósticos y los intervalos de prueba de funcionamiento?

• ¿De donde se obtienen los datos de fallas?

• ¿Intervención humana o SIS automático?

• Arquitectura de SIS

• Tolerancia a falla. Votación

• Cobertura de diagnóstico

• Verificación y Validación

• Instalación, Operación y Mantenimiento

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

�Introducción a la Seguridad Funcional

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Sumario de Accidentes Relevantes

Incidente Fecha Víctimas Fatales Heridos Pérdidas, M$

NyproFlixborough, GB 06/1974 84 36 100

PEMEXMexico City, MX

11/1984 500 4500 50

Union CarbideBhopal, India

12/1984 2500 200.000+ 1000

ShellNorco, LA

05/1988 7 40 500+

PhillipsPasadena, TX

10/1989 23 130+ 750

ARCOChannelview, TX

07/1990 17 ---- 35

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Sumario de Accidentes Relevantes

Incidente Fecha Víctimas Fatales

Heridos Pérdidas, M$

NNPCNigeria

1988 650 1000+

AZFToulouse, Francia 09/2001 31 2500

Repsol YPFPuertollano, España 08/2003 9 40

SonatrachSkikda, Argelia

01/2004 23 74

Refinería BPTexas, USA 03/2005 15 170

ONGCMumbail, India 07/2005 22 200

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� ¿Por qué ocurren?

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Conceptos generales

• Grandes cambios en la industria en los últimos 60 años• Avances tecnológicos

• Nuevos materiales, procesos e industrias

• Aumento en el tamaño de las plantas

• Optimización de los procesos

• Mayor número de personas expuestas a riesgos

• Accidentes Industriales Mayores• Eventos que implican graves riesgos o catástrofes, inmediatos o

diferidos, a personas, comunidades, medio ambiente o a la producción

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Accidentes - Causas más comunes

• Defectos técnicos

• Errores en la operación

• Factor humano – reacción ante peligros

• Pobres prácticas de mantenimiento

• Señales de alarma no jerarquizadas

• Falta de entrenamiento adecuado

• Problemas de comunicación

• Malfuncionamiento de equipos críticos

• Administración de los permisos de trabajo

• Fallas de materiales

• Condiciones extremas de trabajo

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Conceptos generales

• Ocasionalmente, los accidentes mayores ocurren durante el procesamiento o el almacenaje de los materiales o sustancias. Este tipo de accidentes plantean peligros para la salud y la seguridad de los trabajadores, el público y el ambiente. Además, pueden originar una responsabilidad económica para las empresas y la comunidad. El costo real total y las causas raíz de este tipo de accidentes, a veces, no llegan a conocerse con exactitud.

• Nuevas industrias han comenzado a operar utilizando nuevos procesos, utilizando sofisticados sistemas de control y seguridad, pero creando al mismo tiempo nuevos tipos de peligros. Si no se toman las debidas precauciones en el momento apropiado, esos peligros pueden ser el inicio de desastres mayores resultantes en un grannúmero de fatalidades y daños extensos a personas, la propiedad y al ambiente.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Accidentes - Causas

Los accidentes pueden ser causados, generalmente, por fallos o errores humanos, fallas técnicas o fuerzas externas. Estas son el resultado, en general de múltiples causas, principalmente fallas humanas, que no son debidas sólo a los operadores o trabajadores inmediatamente afectados, sino también al personal de mantenimiento, supervisores, diseñadores de plantas y diseñadores y proveedores de equipos.

Las fallas técnicas tienen, en general, su origen en errores humanos tales como un pobre diseño, mantenimiento o uso inapropiado. Por lo tanto, debe prestarse atención a prevenir, disminuir y/o eliminar los errores y fallos humanos en todos losniveles.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Accidentes - Fallas debidas a causas comunes

• Generalmente, un evento o condición puede llevar a un cierto número de fallas o faltas, llamadas fallas con causa común. Un operador no entrenado adecuadamente es muy posible que tome decisiones erróneas. Si una empresa no tiene un programa de capacitación y entrenamiento apropiado puede deberse a que la Gerencia no considera a la seguridad como su prioridad número 1. Esta falencia es, en general, extensiva a cuestiones como mantenimiento y seguridad de la instalación.

• La más peligrosas de las fallas con causa común son de naturaleza organizacional: insuficiente o falta de compromiso con la seguridad, falta de comunicación entre los departamentos, capacitación e información inadecuada a los trabajadores. La falla con causa común más importante suele encontrarse en la estructura gerencial, que puede conducir a un mayor daño. La gerencia de la empresa debe estar totalmente comprometida con la seguridad de la planta y ese compromiso debe ser dado a conocer a todos los empleados, de todos los niveles.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Accidentes - Consecuencias

• Consecuencias inmediatas

Pueden ser fatalidades, daños físicos al personal, daños a las instalaciones de proceso y edificios, contaminación o daños al ambiente. Los más afectados, en primer término son los trabajadores y las instalaciones pero, según sea la magnitud del accidente, este puede afectar seriamente a las comunidades cercanas y al medio ambiente.

• Consecuencias de largo plazo

Los efectos pueden llegar a involucrar tres niveles: la empresa, las comunidades cercanas y el ambiente.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Accidentes – Consecuencias a largo plazo

La empresa puede verse afectada seriamente por la reacción adversa del público, publicidad adversa en los medios, costos de reparación o reemplazo, pérdidas de producción, lucro cesante, demandas judiciales por los distintos afectados.

Las personas que habitan las comunidades cercanas pueden verse afectadas física y psicológicamente. Las consecuencias a la salud por exposición a sustancias químicas pueden ser inmediatas, o pueden manifestarse en el largo plazo. Además, pueden ocurrir daños a la propiedad que deberán ser resarcidos por la empresa. Además, en forma subsidiaria, hay que considerar las probables pérdidas de valor de las propiedades por la percepción de vivir en un área insegura.

El ambiente puede verse seriamente perjudicado por la emisión de sustancias peligrosas que pueden afectar la tierra, los animales, los cursos de agua y/o la vegetación.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� ¿Porqué fallan los Sistemas de Control o de Seguridad?

• Fuente: HSE UK - 1987

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Accidentes Mayores - Lecciones

• Percepción del riesgo

• Desarrollo de respuestas ante la emergencia

• Protocolos de almacenamiento

• Evaluación del potencial de escalado

• Inspecciones y mantenimiento de rutina de equipos críticos

• Sistemas de Control confiables y adecuados

• Ubicación en planta de los edificios principales

• Información al público

•• ComprensiComprensióón de la importancia de la evaluacin de la importancia de la evaluacióón de riesgosn de riesgos

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Sumario de Accidentes Relevantes

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

�Respuesta Gubernamental y Privada

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Medidas Gubernamentales

• SEVESO I – CE 1985

• SEVESO II – CE 1999

• SEVESO III – CE 2003

• OSHA - 1910.119 Process Safety Management Of Highly Hazardous Chemicals – USA 1992

• OSHA - Process Safety Management - USA

• OSHA - Management Of Change - USA

• EPA Risk Management Program – USA 1990

• HSE Health & Safety Executive – GB 1987

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Normas y Prácticas Recomendadas

• IEC 61508 “Functional Safety of E/E/PE safety-related systems ”

• IEC 61511 “ Functional Safety: Safety Instrumented Systems for the Process Industry”

• ANSI/ISA 84.01 “ Application of Safety Instrumented Systems for the Process Industries”

• Health and Safety Executive (HSE) PES Guidelines

• DIN/VDE 0801 “General Safety Principles for Vendors” Derogada

• DIN V 19250 "Fundamental Safety aspects for Measurements and Control Equipment"

• AIChE CCPS “ Guidelines for Safe Automation of Chemical Processes”

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

�Conceptos básicos de seguridad

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Industrias de Procesos

• Principales preocupaciones

• Seguridad

• Disponibilidad

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Seguridad - Definición

Es el estado en el que hay certeza de que no existe la posibilidad de peligro o daño

Significa estar libre de riesgos inaceptables que puedan provocar daños físicos o a la salud de las personas, ya sea en forma directa, o indirecta, como resultado de daños a la propiedad o al ambiente

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Seguridad Funcional

Es la parte de la seguridad general, relacionada con el EBC y del sistema de control del EBC, que depende del correcto funcionamiento de los sistemas E/E/EP relacionados con seguridad en respuesta asus entradas.

La seguridad funcional se alcanza cuando cada función de seguridad especificada cumple con su cometido y el nivel de desempeño requerido de cada función de seguridad es cumplido satisfactoriamente.

Ni la seguridad y/o la seguridad funcional, pueden determinarse sin considerar al sistema como un todo y al ambiente en el que debe interactuar.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Niveles Independientes de Protección

DiseDiseñño delo delProcesoProceso

Sistema BSistema Báásico de Control de Procesossico de Control de Procesos

Alarmas Criticas, IntervenciAlarmas Criticas, Intervencióón del Operadorn del OperadorSistema Instrumentado de SeguridadSistema Instrumentado de Seguridad

ProtecciProteccióón Fn Fíísica Activa (Vsica Activa (Váálvulas de Alivio, Discos de Ruptura)lvulas de Alivio, Discos de Ruptura)

ProtecciProteccióón Fn Fíísica Pasiva (Diques o Barreras de Contencisica Pasiva (Diques o Barreras de Contencióón)n)

Respuesta de Planta a las EmergenciasRespuesta de Planta a las Emergencias

Respuesta de la Comunidad a las EmergenciasRespuesta de la Comunidad a las Emergencias

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� ¿Qué es un Sistema Instrumentado de Seguridad?

• Es un sistema diseñado para responder a condiciones en la planta que pueden ser peligrosas por sí mismas o, si no se toma ninguna acción, pueden, eventualmente, alcanzar un cierto grado de peligrosidad.

Además genera las salidas correctas para mitigar consecuencias peligrosas o para prevenir el peligro.

Fuente: Health and Safety Executive (HSE), 1987.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� SIS - Ejemplos

• Sistemas de parada de emergencia

• Sistemas de fuego y gas

• Control de turbinas

• Supervisión y control de quemadores

• Enclavamientos de seguridad y parada de emergencia en máquinas

• Sistemas de señalamiento de ferrocarriles

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Funciones de Seguridad

Función de Seguridad:

Es una función a ser implementada en un Sistema E/E/PE, otro dispositivo relacionado con seguridad o facilidad externa para reducción de riesgo, cuyo cometido es llevar a, o mantener en, un estado seguro al EBC con respecto a un evento peligroso específico.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Función Instrumentada de Seguridad - SIF

FunciFuncióón Instrumentada de Seguridad: es una funcin Instrumentada de Seguridad: es una funcióón a ser implementada en un n a ser implementada en un SIS, para llevar a, o mantener en, un estado seguro al EBC, con SIS, para llevar a, o mantener en, un estado seguro al EBC, con respecto a un respecto a un

evento peligroso especevento peligroso especíífico.fico.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Función Instrumentada de Seguridad - SIF

• Una función instrumentada de seguridad es simplemente un lazo de control.

• Un SIF contendrá un cierto número de dispositivos y todos esos dispositivos constituyen parte del SIS.

• Un SIS comprende normalmente más de un SIF.

• Un SIF puede incluir muchos sensores y una única válvula de seguridad, o un sensor y más de una válvula de seguridad. Cualquier combinación es posible.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Función Instrumentada de Seguridad - SIF

• Propiedades básicas de las SIF:

• Medición

• Lógica

• Actuación

• Tiempo

• Integridad de la Seguridad

• Otras• Mantenimiento

• Prueba de Funcionamiento

• Condiciones ambientales

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Función Instrumentada de Seguridad - SIF

• Criterio para la asignación de las SIF• Qué hay que proteger?

• Cómo se hace?

• Qué variable hay que medir

• Sobre qué hay que actuar?

• Cuándo hay que hacerlo?

• Cuál debe ser el tiempo de respuesta?

• Bajo qué aplicación?

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Sistema Instrumentado de Seguridad - SIS

• Múltiples SIF, con diferente SIL, dentro de un SIS

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Integridad de la Seguridad

• Probabilidad de que un sistema relacionado con seguridad desempeñe satisfactoriamente la función de seguridad requerida bajo todas las condiciones establecidas y dentro de un período de tiempo especificado.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Nivel de Integridad de la Seguridad - SIL

• Nivel discreto, uno de cuatro posibles, para especificar los requerimientos de integridad de la seguridad de una función de seguridad a ser asignado al Sistema instrumentado de Seguridad, donde el nivel de integridad de la seguridad 4 es el más alto nivel y el nivel de integridad de la seguridad 1 es el más bajo.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Nivel de Integridad de la Seguridad - SIL

• Es una propiedad de la función de seguridad completa.• Cada valor corresponde a un rango seleccionado de

probabilidad de fallas de la función de seguridad.• Es una medida cualitativa de la seguridad.• Es una unidad métrica cuantitativa de la confiabilidad.• No hay regulaciones que asignen un valor SIL a un proceso

particular. No es una medida del riesgo.• La asignación de SIL es una decisión que debe tomar la

empresa. • Cuanto más alto el nivel SIL, más estrictos son los

requerimientos técnicos y administrativos.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Definiciones

¿Qué es disponibilidad?Es la fracción de tiempo en la que un sistema es operacional y en

un determinado instante de tiempo:

A = MTTF / (MTTF + MTTR).

No indica como es el desempeño del sistema durante ese período de tiempo, sólo expresa la probabilidad de que estará operando en un determinado instante entre ciclos de reparación.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Definiciones

• Confiabilidad

Es la probabilidad de que un sistema, incluyendo todo el hardware, software y firmware, desempeñará satisfactoriamente la función para la que ha sido diseñado, sin fallas, dentro de un ambiente especificado y durante un periodo de tiempo especificado.

R (t) = exp ( - (1/MTTF)t) ó R (T) = exp (-�t)

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Definiciones

• Confiabilidad es una función del tiempo operativo.• Todas las funciones de confiabilidad comienzan con

confiabilidad uno y decrecen hasta confiabilidad cero. El dispositivo debe cumplir su función durante el intervalo de tiempo completo.

• La expresión “Confiabilidad = 0.76 para un tiempo de 100.000 hs” tiene perfecto sentido.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Confiabilidad vs. Disponibilidad

• Disponibilidad no es igual a confiabilidad

• Disponibilidad brinda información acerca de cómo Ud. utiliza su tiempo.

• Confiabilidad brinda información acerca del intervalo libre de fallas.

• Ambas se expresan en valores porcentuales (%)

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Nivel de Integridad SIL

Reducción de RiesgoProbabilidad de Falla en Demanda

Safety Integrity Level

10 - 1000.1 – 0.011

100 - 10000.01 – 0.0012

1000 - 100000.001 – 0.00013

10000 - 1000000.0001 – 0.000014

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Estados de los Sistemas de Seguridad

• Un Sistema de Seguridad puede estar en uno de los siguientes estados:

• Normal: no tiene fallas internas

• Seguro: el sistema de seguridad ha fallado de una manera tal que la función de seguridad ha reaccionado tal como fue diseñada aún ante la ausencia de una demanda

• Peligroso: el sistema de seguridad ha fallado de una manera tal que la función de seguridad no reacciona tal como fue diseñada ante una demanda

• Intermedio: la función de seguridad puede aún reaccionar tal como fue diseñada a pesar de la presencia de una o más fallas internas

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Estado Sistema de Seguridad vs. Proceso

Disponible pero es necesario reparar el sistema de seguridad

Estado Intermedio

Disponible pero no protegidoEstado Peligroso

ParadoEstado Seguro

DisponibleEstado Normal

Proceso o EBCSistema de Seguridad

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Fallas en los Sistemas de Seguridad

• Una Falla es el fin de la habilidad de una unidad funcional de desempeñar una función determinada o esperada.

• Falla aleatoria

• Falla sistemática

• Falla de Causa Común

• Falla de Modo Común

• Cualquiera de estas fallas pone al sistema de seguridad en un estado específico.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Fallas en los Sistemas de Seguridad

• Una Falla aleatoria es una falla espontánea de un componente del hardware en cualquier momento.

• Es aquella que ocurre por desgaste del equipamiento debido al uso.

• Permanente – existe hasta que se repara

• Dinámica – existe sólo bajo determinadas circunstancias

• Una Falla sistemática es una falla oculta• Puede ser un error de diseño o implementación.

• Puede ser una falla de hardware o de software.

• Técnicas – hardware o software

• Administrativas – especificaciones de diseño, manuales de usuario, procedimientos

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Fallas en los Sistemas de Seguridad

• Una Falla de Causa Común es una falla resultado de uno o más eventos que causan fallas de dos o más canales separados en un sistema de múltiples canales, conduciendo a una falla de sistema.

• Los eventos deben estar relacionados con eventos ambientales

• Falla de Modo Común es la falla de uno o más canales de la misma manera, causando el mismo resultado erróneo.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Fallas en los Sistemas de Seguridad

Falta

• Condición anormal que podría causar una reducción en, o la pérdida de, la capacidad de una unidad funcional de desempeñar la función requerida.

Error

• Discrepancia entre el valor o condición calculado, observado o medido y el valor o condición real, especificado o teóricamente correcto.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

�Normas, Leyes, Regulaciones

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Normas y Prácticas Recomendadas

• Evolución histórica

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� IEC 61508

Functional safety of E/E/PE safetyFunctional safety of E/E/PE safety--related systemsrelated systemsUna norma internacional para todas las industrias en las que se utilizan

Sistemas Eléctricos / Electrónicos / Electrónicos Programables en

aplicaciones relacionadas con seguridad

Siempre que sea posible, se debe tener una Siempre que sea posible, se debe tener una separaciseparacióón entre las funciones relacionadas con n entre las funciones relacionadas con

seguridad y las que no lo estseguridad y las que no lo estáán.n.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� IEC 61508

• Es una publicación de IEC sobre seguridad

• Es una norma “genérica” de seguridad para ser utilizada cuando en un sector específico de la industria no haya normas de seguridad

• Principalmente se ocupa de Sistemas E/E/PES relacionados con seguridad cuya falla podría tener un impacto en la seguridad de las personas, el ambiente y la propiedad.

• En suma, proporciona una guía para el uso de Sistemas Eléctricos / Electrónicos / Electrónicos Programables en funciones de seguridad

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� IEC 61508

• En 1997 IEC 61508 introduce el Ciclo de Vida de Seguridad, un concepto cuantitativo y cualitativo que incluye el concepto de SIL (Nivel de Integridad de la Seguridad)

• La norma es de aplicación voluntaria

SIN EMBARGO!

• Es una necesidad legal de la industria de cualquier sector utilizar las mejores prácticas para ejecutar esta función

Y

• El estándar IEC 61508 es considerada una “buena práctica” de ingeniería y es mencionada dentro del ámbito legal y jurídico en ciertos países como tal

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� IEC 61508 - Estructura de la norma

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� IEC 61508 – Base para otras normas

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� IEC 61508 – Tecnologías aceptadas E/E/PE

• Relés eléctricos y electro-mecánicos

• Sistemas electrónicos de estado sólido

• Sistemas electrónicos programables, Controladores lógicos programables, Sistemas basados en microprocesadores, Sistemas de control distribuido, Sistemas Abiertos de Control yotros dispositivos basados en microprocesadores, por ejemplo sensores / transmisores / actuadores inteligentes

• Genéricamente, estos sistemas son conocidos en la norma como “Sistemas relacionados con la SEGURIDAD”

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� IEC 61508 – Sistemas Relacionados con Seguridad

• Un sistema relacionado con la seguridad, comprende todo lo necesario ( dispositivos, programas, programación y elemento humano) para llevar a cabo una o más funciones de seguridad, donde la falla de dicha función de seguridad puede dar lugar a un incremento significativo del riesgo, afectando la seguridad de las personas, el ambiente y la producción.

• Un sistema relacionado con seguridad puede comprender equipamiento autónomo dedicado a desempeñar una función de seguridad particular (por ejemplo un sistema de detección de incendio) o puede estar integrado dentro de otro equipamiento o sistema de planta (por ejemplo el control de velocidad de un motor de una máquina herramienta)

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� IEC 61508 – Sistemas Relacionados con Seguridad

• Las consecuencias de una falla podrían tener serias implicancias económicas, en estos casos la norma puede ser utilizada para especificar sistemas E/E/EP relacionados con seguridad para proteger el equipamiento, la planta, el producto y/o la producción.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� IEC 61508 - Ciclo de Vida de Seguridad

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� IEC 61508 – Alcance de la Norma

• Define las actividades del Ciclo de Vida • Desarrollo de los requerimientos generales de seguridad

• Asignación de los requerimientos de seguridad al sistema E/E/EP relacionado con seguridad

• Instalación, comisionado y validación del sistema E/E/EP relacionado con seguridad

• Operación, mantenimiento, modernización, desinstalación o disposición final del sistema E/E/EP relacionado con seguridad

• Describe los requerimientos para la Administración de la seguridad funcional

• Describe los requerimientos para la Evaluación de la seguridad funcional

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� IEC 61511

Functional Safety: Functional Safety:

Safety Instrumented Systems for the Process IndustrySafety Instrumented Systems for the Process Industry

Se ha desarrollado específicamente para la implementación de la IEC 61508 en el

sector de Procesos.

Alcance limitado a Usuarios y a Integradores de Sistemas.

Usuarios e Integradores deben considerar a IEC 61508 como el

requerimiento básico para equipamiento

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Estructura IEC 61511

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Estructura IEC 61511

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Estructura de IEC 61511 vs IEC 61508

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Estado legal de IEC 61508 / IEC 61511

• La adopción de los estándares internacionales IEC por parte de cualquier país, sea o no miembro de IEC, es enteramente voluntario.

Los Comités Nacionales de IEC están encargados de aplicar los estándares internacionales IEC en forma transparente, con la mayor extensión posible dentro de las normas nacionales y/o regionales existentes.

Cualquier divergencia entre las normas internacionales IEC y las normas nacionales en vigencia deberá ser indicado explícitamente dentro del cuerpo de las normas nacionales.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Ciclo de vida de seguridad IEC 61511

Al igual que en IEC 61508, se utiliza como marco para estructurar los requerimientos relativos a especificación, diseño, integración, operación, mantenimiento, modificación y desinstalación de un Sistema de Seguridad.

Cada fase tiene un conjunto definido de entradas y salidas y, hacia el fin de cada fase, una verificación debe ser realizada para confirmar que las salidas obtenidas están de acuerdo con los requerimientos

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

• Ciclo de Vida IEC 61511

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Beneficios de las Normas IEC

• Ofrecen recomendaciones sobre como mejorar la seguridad

• Proveen una guía de buenas prácticas de ingeniería

• Conforman un modelo de gestión de la seguridad

• Proveen un modelo de ciclo de vida de seguridad

• Recomiendan como gestionar la planificación, documentación y evaluación de la seguridad funcional de la planta

No absuelven a los usuarios de su responsabilidad por la No absuelven a los usuarios de su responsabilidad por la seguridad de la planta, los trabajadores, las comunidades seguridad de la planta, los trabajadores, las comunidades

vecinas y el medio ambiente.vecinas y el medio ambiente.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� ANSI/ISA 84.00.01 - 2004

Application of Safety Instrumented Systems for the Process IndusApplication of Safety Instrumented Systems for the Process Industriestries

El SIS debe estar separado del SBCPLos sensores del SIS deben estar separados de los sensores del SBCP.Las áreas de separación son bien claras:

• Procesador lógico• Sensores de campo• Elementos finales de control• Comunicaciones con otros sistemas

Primera edición 1996En su última edición del año 2004, adopta el esquema de la norma IEC 61511

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� AIChE CCPS

Normalmente, el procesador lógico del SIS está separado de su componente similar en el SBCP. Por lo tanto, los sensores y elementos finales decontrol del SIS están, generalmente, separadosde sus similares en el SBCP.

Se debe tener una separación física, funcional e identificación entre los componentes del SBCP y el SIS incluyendo sensores, actuadores, procesadores, módulos de E/S, chasis...

Guidelines for Safe Automation of Chemical Processes (1993)Guidelines for Safe Automation of Chemical Processes (1993)

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Leyes Locales

• Ley 19587 Ley de Higiene y Seguridad en el Trabajo

• Decreto 351/79 Reglamentación Ley 19587

• Ley 24557 Riesgos de Trabajo

• Ley 13660 y Decreto 10877/60 Seguridad de Instalaciones de Elaboración, Transformación y Almacenamiento de Combustibles Sólidos Minerales, Líquidos y Gaseosos

• IEC en Argentina está representado por CEA – ComitéElectrotécnico Argentino.

• CEA depende de AEA y del IRAM.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

�Gestión de la Seguridad Funcional

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Gestión de la Seguridad Funcional

• Un sistema de seguridad es funcionalmente seguro si:

• Las fallas aleatorias, sistemáticas y de causa común no conducen a un malfuncionamiento del sistema de seguridad y no resultan en:

• Daños a la salud humana.

• Incapacidad o fatalidades de personas.

• Pérdidas a la atmósfera de sustancias peligrosas.

• Pérdidas materiales: edificios y equipos.

• Pérdida de capital de trabajo.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Gestión de la Seguridad Funcional - GSF

• GSF es parte de las medidas organizacionales que se toman para lograr una efectiva implementación de los requerimientos técnicos y sólo apunta a lograr y mantener la seguridad funcional de los sistemas relacionadas con seguridad.

• Un buen sistema de gestión de la seguridad funcional básicamente reduce el riesgo ante fallas y garantiza una organización para cumplir los objetivos de seguridad en una dirección estructurada.

• Alcanzar la seguridad no es un tiro con suerte con GSF, sino quees la única vía posible para tener un proyecto exitoso.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Gestión de la Seguridad Funcional - GSF

• Tiene dos objetivos:

• El primero es especificar las actividades técnicas y de gestión generales durante las distintas fases del ciclo de vida del E/E/PES y del software que son necesarios para alcanzar el nivel requerido de seguridad funcional.

• El segundo es especificar las responsabilidades generales de las personas, departamentos y organizaciones responsables de cada fase del ciclo de vida de seguridad o por actividades dentro de cada fase.

GestiGestióón de n de Seguridad Funcional es la clave para garantizar la seguridad.Seguridad Funcional es la clave para garantizar la seguridad.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Gestión de la Seguridad Funcional - GSF

• GSF incluye los siguientes requerimientos:

• Identificación de los individuos, departamentos u organizaciones que serán responsables de cada tarea del ciclo de vida definido en la IEC 61508

• Determinar que las personas que tendrán asignada una responsabilidad son competentes

• Define cuando tendrán lugar las actividades de verificación, evaluación, auditoria y validación

• Requiere procedimientos para la evaluación del desempeño de las SIF después que han sido instaladas

• Requiere que, al menos, se haya realizado una evaluación de seguridad funcional antes de introducir materiales peligrosos en el proceso.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Quienes requieren GSF

• Sistemas típicos relacionados con seguridad:

• Sistemas Parada de Emergencia

• Sistemas de Fuego y Gas

• Sistemas Supervisión de Quemadores – BMS

• Salvaguardas de Turbinas y Compresores

• Sistemas de monitoreo de bombeo gasoductos y oleoductos

• Equipamiento para test de carrera parcial de válvulas

• Industrias típicas que los implementan :

• Petróleo y Gas

• Química

• Petroquímica

• Farmacéutica

• Automotriz

• Automación

• Integradores

• Desarrolladores de productos para esas industrias

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� IEC 61508 vs. IEC 61511

• Para ambos estándares GSF tiene cinco objetivos:• Asegurar que los objetivos de seguridad funcional y de niveles de

integridad de la seguridad son alcanzados para todos los modos de proceso relevantes.

• Asegurar una instalación y comisionado apropiado del SIS.

• Asegurar la integridad de las funciones instrumentadas de seguridad después de la instalación.

• Mantener la integridad de la seguridad durante la operación.

• Gestionar los peligros del proceso durante las actividades de mantenimiento del SIS.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Documentación

• La Seguridad debe ser documentada. La documentación tiene que contener suficiente información necesaria para desarrollar efectivamente:

• Cada fase del ciclo de vida de seguridad

• La gestión de la seguridad funcional

• Las actividades de verificación y validación

• Las evaluaciones de seguridad funcional.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Documentación

Solicitud de modificación, informe de análisis de impacto, aprobación

Cambios y Modificaciones

Registros, informes de auditoriaOperación y Mantenimiento

InformesValidación de la seguridad funcional

InformesInstalación y Comisionado

Diseño del sistema; diseño de hardware; diseño de software; diagramas, manuales, distribución en planta

Realización

PlanPlanificación general de la Instalación y Operación

PlanPlanificación general de la Validación

Especificación con todas las funciones de seguridad y sus propiedades de seguridad funcional

Requerimientos generales de seguridad

Informes HAZOP, FMEA, FTAAnálisis de peligros y de riesgos

Plan de seguridad; Planes de verificación y validaciónTodas las fases

InformaciónFase

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� V & V, Evaluaciones, Auditorias

• Actividades de aseguramiento y gestión de la seguridad funcional:

• Verificación

• Validación

• Evaluación

• Auditoria

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Verificación y Validación

• Verificación: actividad para demostrar, al final de cada fase del ciclo de vida de seguridad, por análisis y/o pruebas, que ante entradas específicas las salidas cumplen en todos los aspectos los objetivos y requerimientos fijados para cada fase. Ejemplos:

• Revisión de los documentos de salida de cada fase

• Revisión de diseños

• Pruebas a los productos diseñados para asegurar que el desempeño es el especificado

• Validación: actividad para demostrar que las funciones instrumentadas de seguridad y los sistemas instrumentados de seguridad bajo consideración después de la instalación cumplen en todos los aspectos con la especificación de requerimientos de seguridad

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Verificación

• Objetivo: demostrar mediante revisión, análisis y/o pruebas que las salidas requeridas, identificadas en el plan de verificación, satisfacen los requerimientos definidos para la fase apropiada del CVS

• Requerimientos: el plan de verificación define las actividades a llevar a cabo:

• Procedimientos, medidas y técnicas

• Cuando se llevan a cabo

• Personas, departamentos u organizaciones responsables, incluyendo nivel de independencia

• Identificación de los puntos s verificar

• Identificación de la información contra la que se lleva la verificación

• Como manejar las no conformidades

• Herramientas de análisis

• Documentación a generar como resultado

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Validación

• Objetivo: validar a través de inspección y pruebas que el SIS instalado y comisionado y sus SIF asociadas cumplen con los requerimientos establecidos en la especificación de requerimientos de seguridad

• Requerimientos: las actividades se definen en el plan de validación:• Validación de todos los modos relevantes de operación el EBC, incluyendo:

• Preparación para su uso, incluyendo ajuste de variables

• Arranque, automático, manual, semi automático, estado estacionario de operación

• Re arranque, parada, mantenimiento

• Condiciones anormales (aquellas posibles)

• Procedimientos, medidas y técnicas a utilizar

• Cuando se hará la validación

• Personas, departamentos u organizaciones responsables, incluyendo nivel de independencia

• Identificación de la información contra la que se lleva la validación

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Validación – Actividades adicionales

• Identificación del software de seguridad que necesita ser validado

• Información de la estrategia técnica de validación• Técnicas manuales y automáticas

• Técnicas estáticas y dinámicas

• Técnicas analíticas y estadísticas

• Ambiente en el que se desarrollará la validación

• Criterio pasa/falla para la validación del software:• Señales de entrada requeridas del proceso y del operador, con secuencias y

valores

• Señales de salida anticipadas con secuencias y valores

• Otros criterios de aceptación, por ejemplo: uso de memoria, tolerancias de tiempos y valores.

• Políticas y procedimientos para la evaluación de los resultados de la validación, en particular las fallas.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Validación - Documentación

• Versión del plan de validación utilizado

• SIF bajo prueba

• Herramientas y equipos usados, con datos de calibración

• Resultados de cada prueba

• Versión de la especificación de prueba usada

• Criterio de aceptación de las pruebas

• Versión del hardware y software bajo prueba

• Cualquier discrepancia entre los resultados obtenidos y los esperados

• En caso de ocurrir una discrepancia, análisis realizado y decisiones tomadas respecto de continuar con las pruebas o solicitar un cambio

• Documentación generada como resultado

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Evaluación de Seguridad Funcional

Es una investigación, basada en evidencia, para juzgar la seguridad funcional alcanzada por uno, o más, sistemas E/E/PE relacionados con seguridad, otros sistemas relacionados con seguridad que emplean otras tecnologías o facilidades externas para la reducción del riesgo.

Esta es una actividad crítica que asegura que la seguridad funcional se ha alcanzado satisfactoriamente. Las personas que ejecutan la evaluación de la seguridad funcional deben ser competentes, deben tener la adecuada independencia y deben considerar las actividades que se llevan a cabo y los resultados obtenidos durante cada fase de cada ciclo de vida y juzgan si se han cumplido los objetivos y requerimientos de IEC 61508.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Nivel de Independencia

HR = Altamente recomendable NR = No recomendado

HRHR--Organización Independiente

NRHRHR-Departamento Independiente

NRNRHRHRPersona Independiente

4321

Nivel de Integridad de la SeguridadNivel Mínimo de Independencia

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Auditorias

• Son similares a las Evaluaciones

• Se enfocan en la implementación general del SIS respecto del ciclo de vida, que permite evaluar la efectividad de la implementación del SIS.

• Es una evaluación realizada en forma periódica

• Aplica a las fases del ciclo de vida más extensas, tal como operación, mantenimiento y reparación

• Los procedimientos de auditoria requieren:• Frecuencia de realización

• Independencia entre las personas que desarrollan las tareas y las que hacen la auditoria

• Registro de resultados y seguimiento

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

�Riesgos y Peligros

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� El Riesgo en la sociedad moderna

• El riesgo no es un problema nuevo. Siempre ha existido.

• La industrialización ha reemplazado los peligros basados en la naturaleza por nuevos basados en la tecnología.

• Todas las actividades humanas involucran riesgo. La sociedad demanda que esos riesgos se controlen o minimicen.

• Además, demanda saber cuáles son los riesgos asociados con las tecnologías peligrosas, los escenarios de caso peor, los peligros de contaminación….

• Eliminar el riesgo es casi imposible. La reducción del riesgo es posible hasta un cierto límite. A partir de allí los costos asociados pueden tornar inviable una inversión o actividad industrial.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Evaluaciones Necesarias

1- ¿Cuáles son las fases peligrosas del Proceso?

- Arranque

- Parada

- Parada de Emergencia

- Cambio de turno

2- ¿Cuáles son las peores consecuencias?

- Muerte

- Lesiones incapacitantes

- Daños al Medio Ambiente

- Daños a la propiedad

- Pérdidas Económicas: producción, lucro cesante, equipos

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Evaluaciones Necesarias

3- Fallas en el Sistema de Seguridad ¿deberán producir paradas de proceso?

- ¿Sensores simples o redundantes?

- ¿Relés o SEPs?

- ¿Solenoides o válvulas?

- ¿Seguridad o disponibilidad?

4- El Sistema de Seguridad ¿deberá tener fallas no detectadas (encubiertas)?

- Diagnósticos limitados -- Relés o SEPs

- SEPs redundantes -- Fallas encubiertas

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Evaluaciones Necesarias

5- ¿Con qué frecuencia deberá verificarse el Sistema de Seguridad?

- ¿1, 2 ó más veces al año?

- ¿En las paradas de mantenimiento?

- ¿Continuamente -- Auto-verificado?

6- ¿Con qué frecuencia ocurriría un accidente sin un sistema de seguridad?

- ¿Muchas veces por año?

- ¿Varias veces por año?

- ¿Pocas veces por año?

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Evaluaciones Necesarias

7- Se trabaja con materias primas peligrosas?

8- Se fabrican productos intermedios peligrosos?

9- El personal que está presente en planta, ya sea propio, contratado, proveedores o visitantes, está debidamente entrenado?

10- Está instalada una cultura en seguridad apoyada y promocionada por la gerencia?

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� El problema es lo que no se ve

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Peligro - Definición

• Una condición física o química que tiene el potencial de causar daño a personas, propiedades o al ambiente (CCPS). Por daño se entiende lesiones físicas o perjuicios a la salud, ya sea en forma directa o indirecta, como resultado de perjuicios a la propiedad o al ambiente.

• Potencial fuente de daño (IEC 61511). El término incluye peligros para las personas que crecen en un corto período de tiempo (por ejemplo, fuego o explosión y también aquellos que tienen efectos de largo plazo sobre la salud de las personas (por ejemplo, emisión de una sustancia tóxica).

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Evento Peligroso - Definición

• Un evento es una situación en general asociada con un incidente, ya sea la causa raíz o una causa contribuyente al incidente.

• Un evento peligroso se produce cuando el peligro potencial ha ocurrido.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Qué es Riesgo?

Riesgo = Consecuencia x Frecuencia

RiesgoRiesgoMedida de potenciales pMedida de potenciales péérdidas econrdidas econóómicas, micas, dadañño a las personas, o dao a las personas, o dañño al ambiente en o al ambiente en ttéérminos de posibilidad de ocurrencia y de rminos de posibilidad de ocurrencia y de magnitud de las consecuencias (pmagnitud de las consecuencias (péérdidas, rdidas, perjuicios o daperjuicios o dañños)os)

Consecuencia: Una medida Consecuencia: Una medida de los efectos esperados de de los efectos esperados de un incidente determinadoun incidente determinado

Probabilidad (Probabilidad (likelihoodlikelihood): Una ): Una medida de la probabilidad esperada medida de la probabilidad esperada o frecuencia de ocurrencia de un o frecuencia de ocurrencia de un eventoevento

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Es posible eliminar todos los Riesgos?

Lleve la consecuencia y/o la frecuencia de

potenciales incidentes a un nivel de riesgo

tolerable

Riesgo Tolerable

Riesgo Intolerable

ALARPALARP

El conceptoEl concepto ALARP ALARP puede ser utilizado cuando se puede ser utilizado cuando se adoptan objetivos de riesgo cualitativos o adoptan objetivos de riesgo cualitativos o

cuantitativoscuantitativos Riesgo Aceptable

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Criterio de aceptabilidad del riesgo

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Riesgos típicos del trabajo

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Estadísticas en Argentina

• Tabla N� 19: Cantidad y distribución porcentual de incapacidades permanentes por tipo de evento, e índice de incidencia. República Argentina, año 2005. Anuario publicado por SRT.

5,65,24,6Incidencia x 1.000 trabajadores

6.000.7495.355.2654.716.556Trabajadores cubiertos

100,0%33.533100,0%27.731100,0%21.625Total5,4%1.7969,0%2.4988,0%1.736Reingreso

8,0%2.6819,7%2.6877,9%1.698Enfermedad profesional

14,7%4.92015,0%4.16615,5%3.342Accidente in itinere

72,0%24.13666,3%18.38068,7%14.849Accidente de trabajo

%Cantidad%.Cantidad%Cantidad200520042003

Tipo de evento

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Criterio de aceptabilidad del riesgo

• El proceso de decisión sobre el nivel de riesgo aceptable es complejo

• Los objetivos son múltiples y, en ocasiones, contradictorios

• Es necesario tomar en cuenta consideraciones humanitarias, económicas, de responsabilidad legal, de responsabilidad social y de imagen pública

• Un riesgo catastrófico es menos aceptable socialmente, que la suma de un conjunto de riesgos de pequeña magnitud, aún cuando el riesgo total para las personas y para la propiedad fuese idéntico

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Porqué hay que bajar el riesgo?

• Mayor compromiso con el cuidado del ambiente

• Protección de los empleados y la propiedad

• Más regulaciones gubernamentales y requerimientos de la sociedad

• Nuevas normas de seguridad

• Litigios legales iniciados por grupos de interés

• Imagen de la compañía

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Reducción de Riesgos

RIESGO

Riesgo Inherenteal Proceso

Nivel de RiesgoAceptable

PROCESO

SIS SBCPSV, RV

RiesgoResidual

Externos Alarma

Integridad Mecánicaequipos, cañerías, etc.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Reducción de Riesgos

• Preguntas aplicables a cualquier industria de procesos

• Cuáles son los peligros?

• Qué puede salir mal y porqué?

• Cuáles son las probabilidades?

• Cuáles son las consecuencias?

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Reducción de Riesgos

• Consecuencias de eventos peligrosos

• Fuego

• Explosión

• Explosión de nube de vapor

• Formación de atmósfera tóxica

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Reducción de Riesgos

• Diferentes terminologías para situaciones peligrosas:

• Escenarios que determinan fenómenos peligrosos de tipo térmico• Incendio de charcos

• Dardos o Chorros de fuego

• Llamarada / Nube de fuego

• BLEVE – Bola de fuego

• Escenarios que determinan fenómenos peligrosos de tipo mecánico• Explosión de nube de vapor (VCE). Confinadas o no confinadas

• Ruptura de alta presión

• Explosión BLEVE

BLEVE: Boiling Liquid Expanding Vapor Explosion

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Medida del Riesgo

• Riesgo individual

• Es la probabilidad de ocurrencia de una consecuencia no deseada debida a un accidente a un ser humano individual que está en un determinado punto (X,Y)

• Riesgo Social

• Expresa la relación entre la frecuencia esperada y el número de personas que sufren un determinado tipo de daño debido a la ocurrencia de un peligro específico

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Riesgo Público o Social – Curva FN para Riesgo Social

Frecuencia

Esperada

Aceptable

Inaceptable

Reducción Deseada

Líneas FN

102 103

105

103

Número N de Probables fatalidades

F

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Cuantificación del nivel del Riesgo

• Para poder decidir si un riesgo es o no aceptable, hay que estimar, de alguna manera su magnitud.

• Esto implica un análisis previo

• Hay que desarrollar una estimación del nivel de peligro potencial de una actividad.

• Estos peligros estarán referidos tanto a personas como a bienes materiales, en términos de magnitud del daño y de la probabilidad de ocurrencia

• Es una herramienta necesaria para la toma de decisiones, ya sea jerarquizando las estrategias de reducción de riesgo o comparando con los niveles de riesgo fijados como objetivo para la actividad en estudio

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

• Los métodos de evaluación de riesgos se pueden dividir en:

• Cualitativos: Evaluación realizada por un experto o panel de expertos que juzgan la frecuencia y las consecuencias de los riesgos. Usualmente el resultado se presenta en formato matriz.

• Cuantitativos: Evaluación realizada utilizando datos de frecuencia de fallas (humanas y de equipos) para calcular la probabilidad de falla ante una demanda y. en algunos casos, modelos de consecuencia para evaluar impacto potencial.

� Evaluación de Riesgos – Técnicas y Métodos

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Objetivos de un Análisis de Riesgo Cualitativo

• Identificación de aquellas desviaciones del proceso que pueden conducir a un evento peligroso.

• Determinación de la severidad de un evento peligroso.

•• El anEl anáálisis debe hacerse asumiendo que no estlisis debe hacerse asumiendo que no estáá presente presente ninguna capa de proteccininguna capa de proteccióón, incluyendo dispositivos de n, incluyendo dispositivos de mitigacimitigacióón pasivos o activos.n pasivos o activos.

• Analiza la probabilidad de ocurrencia de un evento peligroso.

• Hacer recomendaciones concernientes a los métodos de reducción de riesgo necesarios.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Análisis de Riesgo Cualitativo

• Todos los métodos requieren de un equipo de personal especializado en distintas áreas para identificar los peligros asociados al proceso.

• Los efectos de las desviaciones del proceso son examinadas para determinar las áreas de riesgo.

• Los resultados se basan en la aplicación de buenas prácticas de ingeniería.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Análisis de Riesgo Cualitativo

• El equipo debe aplicar técnicas de mitigación en el siguiente orden:

• Cambios en el diseño mecánico del proceso, incluyendo la distribución de los equipos o de la planta.

• Integridad mecánica del equipamiento

• Reemplazo de sustancias utilizadas por el proceso

• Aplicación de SBCP

• Procedimientos de Operación, Mantenimiento y Entrenamiento

• Aplicación de SIS

• Otros sistemas relacionados con seguridad que emplean otras tecnologías

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Niveles Independientes de Protección

• ¿Qué son?

• Usualmente se presentan como las capas de una cebolla.

• Cada capa es independiente en términos de operación

• La falla de una capa no afecta a las otras capas.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Niveles Independientes de Protección

• Restricciones

• Suficientemente independientes de manera tal que la falla en una de las IPL no afecta adversamente la probabilidad de falla de las otras IPL.

• Diseñadas para prevenir eventos peligrosos, o mitigar las consecuencias de un evento peligroso.

• Diseñadas para desempeñar su función de seguridad durante condiciones de diseño normales y anormales.

• Desempeño auditable.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Niveles Independientes de Protección

• IPLs proveen

• Prevención (activa – baja probabilidad)

• Alarmas con respuesta del operador

• Sistema Instrumentado de Seguridad

• Mitigación (activa – baja probabilidad/consecuencia)

• Válvula de alivio de presión

• Protección (pasiva – baja consecuencia)

• Diques

• Diseño mecánico

• Barricadas

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

�Técnicas de Análisis de Riesgo

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Técnicas de Análisis de Riesgo

• Análisis Causa - Consecuencia

• Lista de Verificación

• Análisis Árbol de Eventos

• Análisis Modos de Falla & Efectos (FMEA)

• Análisis Modos de Falla, Efectos & Criticidad (FMECA)

• Análisis Árbol de Fallas (FTA)

• LOPA

• Análisis de Peligros y Operabilidad (HAZOP)

• Confiabilidad Humana

• Análisis de Peligros Preliminares (PHA)

• Identificación de Peligros (Hazid)

• Análisis Qué pasa sí?

• Análisis Qué pasa si?/Lista de Verificación

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� HAZOP

• HAZard: Peligro – Riesgo

• OPerability: Operabilidad

• Análisis de peligros y de operabilidad (HAZard and OPerability studies -HAZOP)

• Las instalaciones son diseñadas para adecuarse a las condiciones normales de trabajo, pero deben ser capaces de soportar alteraciones previsibles, aunque sean ocasionales, sin generar daños a personas y bienes.

• Método diseñado por la ICl en la década de los sesenta para su aplicación en el diseño de plantas para la fabricación de pesticidas, con la finalidad de detectar las situaciones de inseguridad.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

�Características de los Sistemas

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Sistemas de Control

Característica DCS

Operación Normal Dinámico. Activo continuamente

Utilización Continua

Operación Humana Interacción continua

Señales Entrada/Salida Principalmente analógicas

En Servicio/Fuera Servicio Frecuente transf. auto-manual

Test de Fallas En general auto reveladas

Tiempo Medio para Reparar Menos crítico

Interfaz con Operador Dominada por Operadores

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Sistemas de Seguridad

Característica SIS

Operación Normal Pasivo, hasta una demanda

Utilización Intermitente

Operación Humana Interacción infrecuente

Señales Entrada/Salida Principalmente discretas

En Servicio/Fuera Servicio Nunca fuera de línea

Test de Fallas Para revelar fallas ocultas

Tiempo Medio para Reparar Crítico para alta disponibilidad

Interfaz con Operador Sólo informes de estado

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Separación de SBCP y SIS

• En instalaciones de SIS antiguas, la separación fueasegurada debido a que los enclavamientos de seguridad eran típicamente sistemas cableados (harwired) con relés electromecánicos montados en un gabinete cerrado.

• Dos áreas en particular requieren atención especial en el diseño de un SIS: la interfaz Hombre/Máquina y el Programa de Aplicación.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Puedo realizar las funciones de mi SIS en mi SBCP?

• Los expertos en el campo de los sistemas de seguridad no recomiendan realizar las funciones de seguridad de los SIS en los Sistemas Básicos de Control De Procesos (SBCP)

• Las normas IEC 61508 / 61511 y ANSI/ISA 84.00.01- 2004 lo recomiendan fuertemente, excepto para niveles bajos de integridad (Nivel 1).

• La separación de ambas funciones es altamente recomendable.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� SIS vs. SBCP - Porqué deben Separarse

• Se reducen las chances de un error humano.

• Hace que los SIS sean distintos, permitiendo la implementación de precauciones especiales consistentes con las demandas del SIS.

• Garantiza la seguridad y la integridad, permitiendo al SIS alcanzar un nivel de seguridad e integridad igual o mejor que el de los sistemas a relé.

• Asegura que no se realicen cambios no autorizados.

• Elimina las fallas de modo común.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� SIS vs. SBCP - Porqué deben Separarse (cont.)

• Acceso restringido.

• Se asegura que los cambios de software en línea al Sistema de Control SBPC no alteran el programa del SIS.

• Asegura que datos corruptos en el SBPC no corromperán datos en el SIS.

• Permite el uso de software para seguridad, mientras que desacopla al SIS de los cambios inducidos en la programación de control de procesos.

• Facilita el test y el mantenimiento de un equipo independiente.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� SIS vs. SBCP - Porqué deben Separarse (cont.)

• Esquema tradicional

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� SIS vs. SBCP – Tendencia actual

• Funciones de control de procesos y de seguridad integradas en un sistema

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� SIS vs. SBCP – Tendencia actual

• Beneficios de la integración• Mapeo de datos común• Incremento en la seguridad• Herramientas de ingeniería similares• Diferencia visual entre el SBCP y el SIS en la Estación de

Operación• Acceso protegido adecuadamente• Reducción significativa en los esfuerzos de integración• Reducción en los costos de hardware, configuración,

entrenamiento e inventario de partes.

Integrado con, pero separado del, sistema de control

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

�Consideraciones sobre votación

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Votación

• Se define como el número de caminos (M) requeridos del número total de caminos redundantes (N) para desempeñar la función de seguridad.

• En general se los expresa como:• MooN

• XooY

• Por ejemplo 1oo2, 2oo3, 2oo4

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Consideraciones sobre Votación

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Consideraciones sobre Votación

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Consideraciones sobre Votación

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Consideraciones sobre Votación

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Consideraciones sobre Votación

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

�Tipo de Fallas en Sistemas de Seguridad

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Definiciones

• Falla Peligrosa: Falla que tiene el potencial de poner un sistema relacionadocon seguridad en un estado peligroso o en un estado en el que falle en el cumplimiento de la función de diseño.

• Falla Segura: Falla que no tiene el potencial de poner un sistema relacionado con seguridad en un estado peligroso o en el que falle en el cumplimiento de la función de diseño.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Falla Peligrosa

• Fallas peligrosas son aquellas en las que el sistema de seguridad falla de manera tal que el proceso controlado no puede ser parado.

• Fallas encubiertas: Fallas que no se revelan y permanecen escondidas hasta que son descubiertas en un test y son reparadas, por ej.: el flotante de un control de nivel que estápegado, el acoplamiento de una válvula solenoide roto o doblado. Probabilidad de falla peligrosa sobre demanda (PFD(d)) ó PFD.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Falla Segura

• A una parada causada por una falla en el sistema de seguridad y no iniciada por el proceso o una demanda, se la llama falla segura, o disparo falso.

• Aún cuando las fallas seguras no afectan la integridad de la seguridad, no son deseadas. Producen paradas no programadas.

• Fallas descubiertas: Fallas que se auto revelan, es decir que causan alarma, un evento falso, se las llama “fail-safe”. Probabilidad de falla segura sobre demanda (PFD (s)) ó PFS.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� SEP - Tipos de Fallas

Fuente: ISA-TR84.00.02-2002 - Part 1

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Detección de Fallas

• Las fallas pueden ser detectadas de tres formas:

• A través de la operación normal

• A través de pruebas periódicas de funcionamiento

• A través de diagnósticos embebidos en los subsistemas.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� A través de la operación normal

• El comportamiento del proceso revela la existencia de una falla del equipamiento, por ejemplo:

• Parada de una parte del proceso como consecuencia de una falla del sistema de seguridad.

• Este tipo de detección no es aceptable, ya que lo que se desea es tener una operación continua del proceso, sin paradas no programadas.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� A través de pruebas periódicas de funcionamiento

• La prueba periódica de funcionamiento es una prueba manual de funcionamiento del sistema de seguridad, que se realiza según una determinada programación.

• Se inicia por intervención de personal autorizado

• No es una rutina embebida en los sistemas o subsistemas.

• Ejemplo, prueba parcial de funcionamiento de válvulas

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� A través de diagnósticos

• Un Test de diagnóstico es una prueba que se realiza, en general, en forma automática, sin intervención de persona alguna.

• Usualmente son rutinas embebidas en el hardware o software del sistema de seguridad

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Cobertura de diagnóstico

• Se define como la relación entre la tasa de fallas detectadas por los diagnósticos embebidos y la tasa de fallas total del componente o subsistema. La cobertura de diagnóstico no incluye las fallas detectadas en las pruebas manuales.

• Conociendo la cobertura de diagnóstico, se pueden calcular las tasas de fallas detectadas y no detectadas.

• DC = � detectadas / � total

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Fracción de Falla Segura - SFF

• Definición

� Tasa de falla Segura + � Tasa de Falla Peligrosa Detectada

SFF = -------------------------------------------------------------------------------------

� Tasa de Falla Total

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� SEP - Datos de Ocurrencia de Fallas

• En general los datos de ocurrencia de fallas indican la velocidad de ocurrencia de fallas encubiertas y descubiertas. Por ejemplo, un PLC con CPU doble tiene una velocidad de ocurrencia de fallas de una por año y una velocidad de falla encubierta de una cada 5 años.

• Los mejores datos de velocidad de ocurrencia de fallas vienen de los datos de su propia planta, por lo que es aconsejable llevar un registro de mantenimiento confiable.

• Sea cuidadoso con los datos suministrados por los fabricantes.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Fuentes a consultar para la obtenciónde datos de ocurrencia de fallas

• OREDA - Offshore Reliability Data Base – DNV

• CCPS - Process Equipment Reliability Data

• SINTEF - Reliability Data for Control & Safety Systems

• IEEE STD - 500 – 1984 para Usinas Nucleares

• SRD - Safety and Reliability Directorate - UK

• NPRD - 95 Nonelectronic Parts Reliability Data

• FMD – 97 Failure Mode Mechanism Distributions

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

�Sistemas Instrumentados de Seguridad

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� SIS - Requerimientos

• El sistema de seguridad o de control crítico debe funcionar en respuesta a una demanda, cada vez que sea necesario, tal como fue diseñado y no debe generar entradas y salidas erróneas.

• “Defecto Cero”

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Cuál es la función del SIS?

Alto Nivel

Valor de Proceso

Bajo Nivel

Comportamiento Normal

Tiempo

Alarma Alto NivelOperador toma acción

Nivel Disparo

Nivel Seguridad Mecánica

Controlado por SIS

Acción Parada Emergencia

Boom!

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Planificación del Sistema de Seguridad

• Los Usuario e Integradores de Sistemas de Seguridad deben planificar las actividades que se llevarán a cabo como parte del Ciclo de Vida de Seguridad.

• Deben elaborar:• Plan de Seguridad

• Plan de Operación y Mantenimiento

• Plan de Instalación y Comisionado

• Plan de Validación

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Plan de Seguridad

• En el Plan de Seguridad se establece cómo se alcanzarála seguridad funcional.

• Contenido típico:

• Ciclo de Vida con sus distintas fases

• Personas, departamentos y organizaciones involucradas incluyendo sus responsabilidades

• Herramientas, técnicas, etc. que se utilizarán

• Medidas para controlar y evitar fallas

• Procedimientos para Modificaciones

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Plan de Operación y Mantenimiento

• El objetivo de los requerimientos de esta sub-cláusula es el desarrollo de un plan para la Operación y Mantenimiento del sistema E/E/PE relacionado con seguridad, para asegurar que la seguridad funcional requerida es mantenida durante la operación y el mantenimiento.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Plan de Validación

• El objetivo de los requerimientos de esta sub-cláusula es el desarrollo de un plan para facilitar la validación general de la seguridad del sistema E/E/PE relacionado con seguridad.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Plan de Instalación y Comisionado

• El primer objetivo de los requerimientos de esta sub-cláusula es el desarrollo de un plan para la instalación del sistema E/E/PE relacionado con seguridad de una manera controlada, para asegurar que la seguridad funcional requerida es alcanzada.

• El segundo objetivo de los requerimientos de esta sub-cláusula es el desarrollo de un plan para el comisionado del sistema E/E/PE relacionado con seguridad de una manera controlada, para asegurar que la seguridad funcional requerida es alcanzada.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Planificación del Sistema de Seguridad

• Requerimientos

• En este punto el Usuario ya ha decidido:

• Cuales son las funciones de seguridad.

• Cuales son funciones instrumentadas de seguridad

• Tecnología que se va a implementar

• Necesita obtener información y documentación de sus proveedores para planificar las distintas actividades.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

�Especificación de Requerimientos de Seguridad

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� SRS – Qué es?

• Las Especificaciones de Diseño de los Sistemas Instrumentados de Seguridad incluyen:

• Requerimientos de entrada

• Requerimientos de Integridad de la Seguridad

• Requerimientos Funcionales de Seguridad

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

La Especificación de Requerimientos de Seguridad (SRS) es una documentación requerida por las normas IEC 61511, IEC 61508 y ANSI/ISA S84.00.01-2004

Contiene tanto los requerimientos funcionales de seguridad como los requerimientos de integridad de la seguridad. La SRS sirve de fundación para el diseño del sistema instrumentado de seguridad (SIS).

Todos los pasos del ciclo de vida seguridad que se tomen deben ser siempre verificados con los datos de la SRS.

La SRS típicamente incluye lo siguiente:

� SRS – Qué es?

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

• Identificación de los eventos peligrosos asociados con la unidad de procesos en estudio

• Identificación de las causas del evento peligrosos• Determinación de la frecuencia de ocurrencia de los eventos

peligrosos• Evaluación de las consecuencias del evento, en términos de

impactos en la seguridad, el ambiente y económico.• Evaluación de las capas de protección disponibles para mitigar

los efectos del incidente• Determinación de las acciones de mitigación• Selección del nivel de integridad de seguridad para cada SIF y

SIS requerido

� SRS – Qué incluye?

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� SRS – Requerimientos Funcionales de Seguridad - Detalles

• Estado seguro del proceso

• Rango y límites operativos de las entradas normales de proceso

• Entradas de proceso y puntos de disparo

• Salidas a proceso y acciones

• Relaciones funcionales. Modos de Falla

• Requerimientos para parada manual y reset

• Requerimientos de Mantenimiento / Bypass

• Requerimientos de tiempo de respuesta

• Requerimientos de interfaz Humano - Máquina

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� SRS – Otros Documentos Funcionales

• Consideraciones de fallas de causa común

• Requerimientos para la puesta en marcha

• MTBF del equipamiento utilizado para el cálculo de confiabilidad

• Requerimientos de equipamiento regulatorio que tenga impacto en el SIS

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� SRS – Para qué?

• Canaliza y combina información crítica en estructuras de datos administrables.

• Permite una organización y diseño de procesos eficiente reduciendo confusión y reingeniería.

• Provee un documento “vivo” de las razones que existen detrás del diseño del sistema.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� SRS – Cómo se Desarrolla?

• Recursos

• Equipo de profesionales y técnicos con experiencia en Ingeniería de Detalle, Equipos de Proceso y/o Operación de Planta

• Modelado del Proceso• Información de otros procesos similares• Políticas y procedimientos corporativos para evaluación

de riesgos• Normas y Recomendaciones de Diseño corporativas

• Grupo de Instrumentos lidera el Equipo

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Cuando se debe iniciar un SRS?

• Cuando se diseñan nuevos sistemas o nuevas plantas

• Cuando se modifican plantas, equipos o sistemas existentes

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

�Evolución

Ing. Qco. Roberto E. Varela ©

� Tecnologías Disponibles

Sistemas cableados de estado sólido

Sistemas cableados basados en relés

Sistemas electrónicos programables

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Sistemas basados en relés

• Primer sistema de protección industrial

• Aún es considerado uno de los sistemas más confiables debido a su alto – 98% - predecible modo de falla.

• En algunas industrias y aplicaciones un 2% de modo de falla no predecible es un valor totalmente inaceptable.

• Inmunidad a la interferencia

Electromagnética.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Sistemas basados en relés - Desventajas

• No son necesariamente seguros ante falla porque:

- el contacto del relé puede quedar pegado en una posición cerrado por suciedad o por inducción.

- se puede quebrar el resorte

- los contactos se pueden quemar

- los brazos del contacto se pueden quebrar

- ocupan demasiado espacio en los gabinetes (si se agregan temporizadores mayor aún es el espacio requerido)

• Requieren de un ambiente controlado para mantener la integridad de los contactos, a menos que se utilicen relésherméticamente sellados.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Sistemas basados en relés - Desventajas

• Sistemas complejos, difíciles de diagnosticar y mantener.

• Documentación puede ser compleja de leer y de modificar.

• Redundancia difícil de implementar.

• Sólo pueden implementarse entradas y salidas digitales.

• No hay comunicación.

• No hay diagnósticos para detectar fallas internas.

• Las modificaciones son difíciles de implementar.

• Al estar energizados en forma continua se reduce el MTBF.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Sistemas cableados de Estado Sólido

• Se utilizan principalmente para la seguridad de maquinaria (deben energizarse para disparar)

• Se han implementado en la industria de refino de petróleo en los cracking catalíticos (desenergizar para disparar, seguros ante falla)

• Aplicaciones en sistemas de supervisión y control de quemadores de calderas

• Cada módulo tiene una función lógica específica

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Sistemas cableados de Estado Sólido - Comentarios

• Sus principales componentes (transistores, diodos, triacs) fallan de manera impredecible, 50% y 50%

• No son flexibles si es necesario introducir cambios.

• Tienen la posibilidad de implementar diagnósticos limitados a través de LEDs.

• Su modificación puede ser compleja si no incluyen una placa base cableada.

• Facilidad para la búsqueda de falla y test.

• No son flexibles si es necesario introducir cambios.

• No requieren programación

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Controladores Lógicos Programables PLCs

• Texas Instruments inventa el circuito integrado (CI) en 1958

• El CI abre el camino para el desarrollo de Microcomputadores Programables y Microprocesadores que constituyen la unidad central de procesamiento.

• A través de la codificación con un software se reemplazan a los sistemas basados en relés y a los de estado sólido.

• Las funciones lógicas y secuenciales se ejecutan en la CPU

• Ampliamente aceptados en la industria automotriz

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Controladores Lógicos Programables PLCs

• Es un Sistema relacionado con seguridad?

• Modo de falla similar al de los sistemas de estado sólido: desconocido.

• Se requiere redundancia para ser seguro ante falla.

• Hay dudas respecto a su comportamiento ante fallas seguras y disparos espurios.

• Baja disponibilidad en configuración simple

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Esquema PLC Redundante

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Ventajas de PLC Redundantes

• Son aceptable para aplicaciones “energizar para disparar (ETT)”

• Disponibilidad de entradas y salidas digitales y analógicas.

• Los puntos de disparo son fáciles de ajustar

• Mejores diagnósticos que en los sistemas de estado sólido

• Comunicaciones con protocolos estandarizados

• Diagnósticos limitados.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� PLC - Desventajas

• Los disparos falsos o espurios son comunes en las aplicaciones “desenergizar para disparar”.

• En caso de falla: cuál es el procesador correcto, A o B?

• Si se produce una comparación errónea, el sistema debe estar programado para parar.

• Errores en las comparaciones resultan en muchos disparos falsos.

• Los cambios a los programas en operación son muy riesgosos.

• Las reparaciones en operación son muy riesgosas.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Sistemas EP Tolerantes a Fallas

• Es un sistema capaz de continuar en operación aún cuando una unidad interna haya fallado.

• Esta capacidad se alcanza replicando una, dos, tres, n veces, los componentes internos del sistema.

• No existen puntos únicos de falla.

• Aplicaciones típicas:

• Parada de emergencia de Hornos

• Supervisión y control de quemadores

• Sistemas protectivos de maquinarias

• Reactores exotérmicos

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Esquema SEP Triple Redundante

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� SEP - Diseño 1oo2D

Input Input CircuitCircuit

Diagnostic Diagnostic Circuit Circuit

CPUCPU

Diagnostic Diagnostic Circuit Circuit

Output Output CircuitCircuit

Diagnostic Diagnostic Circuit Circuit

Input/Output Input/Output ModuleModule

Input/Output Input/Output ModuleModuleCPU ModuleCPU Module ++

Input CircuitInput Circuit

Diagnostic Diagnostic Circuit Circuit

CPUCPU

Diagnostic Diagnostic Circuit Circuit

Output Output CircuitCircuit

Diagnostic Diagnostic Circuit Circuit

Input/Output Input/Output ModuleModule

Input/Output Input/Output ModuleModuleCPU ModuleCPU Module Fi

nal E

lem

ent

Fina

l Ele

men

t

Sen

sor

Sen

sor

--

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� SEP - Desempeño de un Sistema Dual

Probabilidad de Falla

Segura Peligrosa

(1oo1)(1oo1) 0.040.04 0.020.02

BB

AA

AA

BB

((muy seguro, pero mmuy seguro, pero máás s disparos falsos que el simple)disparos falsos que el simple)

((pocos disparos falsos, pocos disparos falsos, pero menos pero menos seguro seguro que el simpleque el simple))

1oo21oo2 0.080.08 0.00040.0004

2oo22oo2 0.040.040.00160.0016

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� SEP - Desempeño de un Sistema Triple

Probabilidad de Falla

Segura Peligrosa

(1oo1)(1oo1) 0.040.04 0.020.02(1oo2)(1oo2) 0.080.08 0.00040.0004(2oo2)(2oo2) 0.00160.0016 0.040.04

AA

BB

CC

Maj

ority

Vot

e

2oo3 2oo3 0.00480.0048 0.00120.0012

1oo2D 1oo2D

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

�Técnicas de selección de SIL

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Cómo se selecciona el SIL a partir de un Análisis Cualitativo?

• No hay una respuesta simple para esta pregunta.

• Algunas compañías dicen “ Un sistema de seguridad es un sistema un sistema de seguridadde seguridad por lo que el SIL debe ser SIL 3”.

• Un método es asignar correlaciones entre SIL y las matrices de riesgo corporativas

• Las Normas IEC 61508 e IEC 61511 presentan distintos métodos que pueden aplicarse para la selección del SIL.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Asignación de SIL

• Rol de los SIS para alcanzar la reducción de riesgo necesaria

Consecuencias de eventos peligrosos

Frecuencia de eventos peligrosos

Riesgo del

proceso

Capas de protección

no SISSIS

Otras capas de protección

Reducción de riesgo necesaria

La integridad de seguridad de capas de protección para prevención / mitigación no SIS y de SIS proveen la reducción de riesgo necesarias

Riesgo tolerable objetivo

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� IEC 61508 - Métodos para la Asignación de SIL

• Cuantitativo

• Cualitativo – Método ALARP

• Cualitativo - Gráficos de Riesgo

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� IEC 61511 - Métodos para la Asignación de SIL

• Semicuantitativo – HazOp + Arbol de Falla

• Cualitativo - Matrices de Riesgo

• Semicualitativo - Gráficos de Riesgo calibrado

• Cualitativo - Gráfico de Riesgo

• Cuantitativo - LOPA

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Matriz de Riesgo de varios niveles

• Se puede establecer una matriz de riesgo de acuerdo a las guías y normas corporativas. Método cualitativo.

• La matriz de riesgo se basa en distintos niveles de:

• Severidad del Evento

• Probabilidad de ocurrencia del Evento

• Capas múltiples de protección

• La matriz de riesgo debe incluir asignaciones de nivel de integridad de la seguridad de acuerdo a lo establecido en IEC 61511

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Matriz de Riesgo - Severidad del Impacto de un Evento

Daños menores al equipamiento. No hay parada del proceso. Daños leves al personal y al ambienteMenor

Daños al equipamiento. Parada del proceso por corto tiempo. Daños severos al personal y al ambienteSeria

Daños al equipamiento severos. Parada del proceso por largo tiempo. Consecuencias catastróficas para el personal y el ambiente

Extensa

ImpactoEstimación de la

Severidad

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Matriz de Riesgo - Probabilidad de un Evento

AltaEventos tales como pérdidas en procesos, fallas en válvulas e instrumentos, o errores humanos que resulten en una pequeña fuga de materiales peligrosos

MediaEventos tales como fallas en válvulas y en instrumentos, o escape mayor en áreas de carga / descarga

BajaEventos tales como múltiples fallas de diversos instrumentos y válvulas, múltiples errores humanos en un ambiente libre de estrés, o fallas espontáneas de recipientes de proceso

ProbabilidadTipo de Evento

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Matriz de un solo Nivel

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Matriz de Varios Niveles

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� IEC 61511- Gráfico de Riesgo Calibrado

IEC 61511 describe el método “Gráfico de Riesgo Calibrado” es un método semicualitativo para la determinación del SIL de una Función Instrumentada de Seguridad a partir del conocimiento de los factores de riesgo asociados con el Proceso, el Equipo Bajo Control y el Sistema de Control asociado a éste.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� IEC 61511- Gráfico de Riesgo Calibrado

• Los parámetros a evaluar son:

• Consecuencia C

• Ocupación F

• Probabilidad de falla en Evitar el Evento Peligroso P

• Tasa de Demanda W

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� IEC 61511- Gráfico de Riesgo Calibrado

Starting point

for risk reduction

estimation

a

b

1

1

2

2

23

3

34

4

C = Consequence risk parameter

F = Frequency and exposure time risk parameter

P = Possibility of failing to avoid hazard risk parameter

W = Probability of the unwanted occurrence

a

a

1

--- ---

---

--- = No safety requirements

a = No special safety requirements

b = A single E/E/PES is not sufficient

1 , 2 , 3 , 4 = Safety integrity level

W W W123

C

C

C

C

F

F

P

P

P

A

B

D

C

A

B

F

F

P

P

P

A

B A

B

A

B

B

A

A

F

F P

PA

B

B

X

X 6

X 5

X4

X3

X 2

1

Generalized arrangement

(in practical implementations

the arrangement is specific to

the applications to be covered

by the risk graph)

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� IEC 61511- Gráfico de Riesgo

IEC 61511 describe el método “Gráfico de Riesgo”. Es un método cualitativo para la determinación del SIL de una Función Instrumentada de Seguridad a partir del conocimiento de los factores de riesgo asociados con el Proceso y el Sistema de Control de procesos.

Este método se basa en el método utilizado en la norma DIN V 19520, 1994 – Control Technology: Fundamental safety aspects to be considered for measurement and control equipment

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� IEC 61511- Gráfico de Riesgo

• Los parámetros a evaluar son:

• Consecuencia - C

• Frecuencia de la presencia en la zona peligrosa multiplicada por el tiempo de exposición - F

• Posibilidad de evitar las consecuencias del evento peligroso - P

• Probabilidad de ocurrencia no deseada - W

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� IEC 61511- Gráfico de Riesgo

(1,2,3,4,5,6,7 y 8) representan la reducción de riesgo mínima. El vínculo entre la reducción de riesgo mínima y el SIL se muestran en la siguiente tabla

Punto de arranque para la estimación de Reducción de Riesgo

2

1

3

4

5

6

7

8

-

12

3

4

5

6

7

-

1

3

4

5

6

P1

P2

P1

P2

F1

F2

F1

F2

C1

C2

C3

C4

W3 W2 W1

C= ConsecuenciaF= Frecuencia y Tiempo ExposiciónP= Posibilidad Evitar Evento PeligrosoW= Probabilidad Ocurrencia No Deseada

-

2

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� IEC 61511- Gráfico de Riesgo - Nivel de Riesgo vs. SIL

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� LOPA - Método Cuantitativo

• Este método se inicia a partir de los datos obtenidos en el estudio HAZOP y detalla cada uno de los peligros identificados documentando la causa inicial y las capas de protección que previenen o mitigan el peligro.

• La reducción de riesgo total puede ser determinada y se analiza la necesidad, o no, de una mayor reducción de riesgo.

• Si se requiere una mayor reducción de riesgo y esta puede ser provista en la forma de una SIF, la metodología LOPA permite la determinación del valor de SIL que corresponde a la SIF.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� LOPA - Método Cuantitativo

PELIGRO PROBABILIDAD RIESGO

PELIGRO PROBABILIDAD PROBABILIDAD PROBABILIDAD RIESGO

MUY ALTO

ACEPTABLE

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� LOPA - Niveles Independientes de Protección

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� LOPA - Niveles Independientes de Protección

• Un Nivel Independiente de Protección (IPL en inglés) es una capa de protección que prevendrá que un escenario inseguro progrese, en forma totalmente independiente del evento iniciador o del desempeño de otra capa de protección.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� LOPA - Implementación

1. Estimación de las consecuencias y de la severidad

2. Desarrollo del escenario

3. Identificación de la frecuencia del evento iniciador

4. Identificar las capas independientes de protección relacionada

5. Identificar el escenario de la frecuencia

6. Tomar una decisión sobre el riesgo

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� LOPA - Niveles Independientes de Protección

IPL1 IPL2 IPL3

Escenario de consecuencia

Evento Iniciador

FallaPFD1 = y1f1 = x * y1

Éxito

Éxito

Resultado seguro

La Flecha representa severidad y frecuencia del Impacto del Evento si la última IPL no es exitosa.

Impacto del evento

frecuencia

PrevenciónPrevención Prevención

Riesgo no mitigado

Reducción de frecuencia para obtener riesgo

tolerable

Riesgo mitigado = frecuencia reducida * misma consecuencia

consecuencia

Estimated Frequencyf1 = x

FallaPFD2 = y2f2 = x * y1 * y2

FallaPFD3 = y3f3 = x * y1 * y2 * y3

Resultado seguro

Resultado seguro

Éxito

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� LOPA - Ejemplo

• Frecuencia Aceptable del Riesgo

• Frecuencia del Evento Iniciador

• PFD IPL1 – Diseño del Proceso

• PFD IPL2 – Sistema de Control de Procesos SBCP

• PFD IPL3 – Alarmas + Operador

• SIL (1 – 3) Requerido por la SIF

• 10 * E - 7

• 10 * E - 1

• 10 * E - 2

• 10 * E - 1

• 10 * E - 1

• 10 * E - ?

• Requerido por la SIF = 10*E-7 / 10*E-1 x 10*E-2 x 10*E-1 x 10*E-1 = 10*E-2

• SIL = 10 * E - 2

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� LOPA – Planilla Informe

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� LOPA – Datos de Hazop

Frecuencia de la CausaProbabilidad Iniciadora

Severidad de la ConsecuenciaNivel de Severidad

Salvaguardas existentesCapas de Protección

Salvaguardas nuevas recomendadasMitigación adicional requerida

CausaCausa Iniciadora

ConsecuenciaImpacto del Evento

Información suministrada por HazopInformación requerida por LOPA

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� LOPA - Características

• A Favor• Altamente auditable, se asigna un valor a cada etapa

• Claridad, es relativamente fácil ver como se han obtenido los resultados

• Permite menor dependencia de los juicios cualitativos

• En Contra• Fijar el Criterio de Tolerancia al Riesgo puede ser dificultoso

• Se requieren gran cantidad de datos de entrada

• Decidir una real independencia es problemático

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Factores Clave para la Selección del Método para Determinar el SIL

• Métodos de Análisis de Riesgo existentes en la Empresa

• Complejidad del Proceso

• Comprender el Proceso (experiencia y conocimiento)

• Consistencia en la designación de los miembros del Equipo de Diseño

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

�Diseño de Hardware

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Ciclo de Vida del Hardware

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Hardware – Conceptos importantes

• Bases para la selección:

• Energizar vs. Desenergizar• Redundancia vs. Diversidad• Demanda Baja, Alta o Continua• Selección de Componentes• Tolerancia a Fallas de Hardware• Restricciones a la arquitectura• Probabilidad de Falla ante una Demanda

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Energizar vs. Desenergizar

• Para que la función de seguridad cumpla su cometido debemos seleccionar el modo de disparo:

• Desenergizar para disparo

• Energizar para disparo

• Cuál es la diferencia?• Desenergizar para disparar, el sistema, o subsistema, no requiere

de energía para desempeñar su función de seguridad.

• Apertura del relé de un presostato para que se pare una bomba.

• Energizar para disparar, el sistema, o subsistema, requiere de la presencia de energía para desempeñar su función de seguridad.

• Accionamiento de un cilindro de gas CO para apagar un incendio

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Redundancia

• IEC 61511 la define como el uso de múltiples elementos o sistemas, para desempeñar una misma función.

• La redundancia puede ser implementada por elementos idénticos (redundancia idéntica), o por elementos diversos (redundancia diversa).

• Se utiliza, primariamente, para mejorar la confiabilidad o la disponibilidad.

+ ó

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Diversidad

• IEC 61511 la define como la existencia de medios diferentes para desempeñar una función de seguridad.

• La diversidad puede llevarse a cabo utilizando diferentes medios físicos o diferentes enfoques de diseño.

• Es un medio de reducir las fallas de causa común.

+

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Nivel de Integridad de la Seguridad

Tabla 2 — Niveles de Integridad de la Seguridad: medidas de falla meta para funciones de seguridad, asignadas a un sistema E/E/PE relacionado con seguridad operando en modo de operación de baja demanda. IEC 61508

≥≥≥≥ 10-2 to <<<< 10-11

≥≥≥≥ 10-3 to <<<< 10-22

≥≥≥≥ 10-4 to <<<< 10-33

≥≥≥≥ 10-5 to <<<< 10-44

Operación en modo de baja demanda(Probabilidad promedio de falla para desempeñar su función

de diseño ante una demanda)

Nivel de Integridad de la Seguridad

Fuente: IEC 61508-1

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Nivel de Integridad de la Seguridad

≥≥≥≥ 10-6 to <<<< 10-51

≥≥≥≥ 10-7 to <<<< 10-62

≥≥≥≥ 10-8 to <<<< 10-73

≥≥≥≥ 10-9 to <<<< 10-84

Modo de operación de alta demanda o continuo(Probabilidad de falla peligrosa por hora)

Nivel de Integridad de la Seguridad

Tabla 3 — Niveles de Integridad de la Seguridad: medidas de falla meta para funciones de seguridad, asignadas a un sistema E/E/PE relacionado con seguridad

operando en modo de operación de alta demanda o continuo. IEC 61508

Fuente: IEC 61508-1

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Nivel de Integridad de la Seguridad

• IEC 61511 cambia la definición de modo de operación:• El modo demanda utiliza la Tabla 3: Probabilidad de Falla ante una

Demanda

• Para modo continuo se usa la Tabla 4: Frecuencia de fallas peligrosas

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Nivel de Integridad de la Seguridad

• Probabilidad de falla ante una demanda

1

2

3

4

Nivel de Integridad de la Seguridad

> 10 a ���� 100≥≥≥≥ 10-2 to <<<< 10-1

> 100 a ���� 1000≥≥≥≥ 10-3 to <<<< 10-2

> 1000 a ���� 10000≥≥≥≥ 10-4 to <<<< 10-3

>10000 a ���� 100000≥≥≥≥ 10-5 to <<<< 10-4

Meta de reducción de riesgo

Meta de probabilidad promedio de falla ante una demanda

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Nivel de Integridad de la Seguridad

• Frecuencia de fallas peligrosas en la SIF

≥≥≥≥ 10-6 to <<<< 10-51

≥≥≥≥ 10-7 to <<<< 10-62

≥≥≥≥ 10-8 to <<<< 10-73

≥≥≥≥ 10-9 to <<<< 10-84

Meta de frecuencia de fallas peligrosas para desempeñar la función instrumentada de seguridad (por hora)

Nivel de Integridad de la Seguridad

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Contribución al SIL

No es posible ordenar solamente un SEP SIL 3 y creer que ya se está cumpliendo con los requerimientos de la

Norma IEC 61508 ó IEC 61511

Sensor

30 %Elemento Final

50 % - 55%

Logic Solver

15%

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Arquitectura Tolerante a Fallas

• Definición de Tolerancia a Fallas

La tolerancia a fallas del hardware, es la habilidad de un componente o subsistema de continuar estando disponible para desempeñar la función instrumentada de seguridad requerida, en presencia de una o más fallas peligrosas en el hardware.

Una tolerancia a fallas del hardware igual a 1 significa que hay, por ejemplo, dos dispositivos y la arquitectura es tal que, la falla de uno de los dos componentes o subsistemas, no impedirá la ocurrencia de la acción segura.

Tolerancia a Fallas N, significa que son necesarias N + 1 fallaspara que la función de seguridad quede inhibida.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Arquitectura Tolerante a Fallas

• Es importante notar que los requerimientos de tolerancia a fallas del hardware representan la redundancia mínima de componentes o subsistemas.

• Dependiendo de la aplicación, la tasa de fallas del componente o subsistema y el intervalo de prueba, puede requerirse redundancia adicional para satisfacer el nivel SIL de la SIF.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Arquitectura Tolerante a Fallas

• La Tolerancia a Fallas depende enteramente de la redundancia de componentes

• La Redundancia facilita la ejecución de las fases

• Redundancia significa necesariamente replicar n veces los componentes

• La Redundancia se aplica a cualquier nivel

EntradaEntrada

EntradaEntrada

SalidaSalida

SalidaSalida

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� IEC 61508 - Subsistemas Tipo A

• Un subsistema es clasificado Tipo A si:

• Los modos de falla están bien definidos.

• El comportamiento de la falla puede ser determinado completamente.

• Está disponible suficientes datos de falla.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� IEC 61508 – Restricciones en Arquitectura

• Tabla 2 — Integridad de seguridad del hardware: restricciones en la arquitectura de subsistemas relacionados con seguridad Tipo A

SIL4SIL4SIL3> 99 %

SIL4SIL4SIL390 % - < 99 %

SIL4SIL3SIL260 % - < 90 %

SIL3SIL2SIL1< 60 %

210

Tolerancia a Fallas del hardwareFracción de falla segura

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� IEC 61508 - Subsistemas Tipo B

• Un subsistema es clasificado Tipo B si:

• Uno o más modos de falla no están bien definidos.

• El comportamiento de la falla no puede ser determinado completamente.

• No están disponibles suficientes datos de falla.

• Si el componente incluye circuitos integrados, se puede asegurar 99.9% que es un subsistema tipo B.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� IEC 61508 – Restricciones en Arquitectura

• Tabla 3 — Integridad de seguridad del hardware: restricciones en la arquitectura de subsistemas relacionados con seguridad Tipo B

SIL4SIL4SIL3> 99 %

SIL4SIL3SIL290 % - < 99 %

SIL3SIL2SIL160 % - < 90 %

SIL2SIL1No permitido< 60 %

210

Tolerancia a Fallas del hardwareFracción de falla segura

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� IEC 61511 – Restricciones en Arquitectura

• Tabla 5 – Hardware mínimo para Tolerancia a Fallas de procesadores lógicos EP

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� IEC 61511 – Restricciones en Arquitectura

• Tabla 6 – Hardware mínimo para Tolerancia a Fallas de sensores y elementos finales y procesadores lógicos no EP

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Reducción de Tolerancia a Fallas de Hardware

• La Norma IEC 61511 establece que se puede reducir el requerimiento de tolerancia a fallas de hardware en 1 si:

• El dispositivo de hardware ha sido elegido considerando Uso Previo.

• Solamente pueden ajustarse parámetros relacionados con el proceso.

• El ajuste de los parámetros de proceso está protegido.

• El SIL es menor que 4.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Incremento de Tolerancia a Fallas de Hardware

• La Norma IEC 61511 establece que se debe incrementar el requerimiento de tolerancia a fallas de hardware en 1 si:

• La falla dominante no es el estado seguro.

• Fallas peligrosas no han sido detectadas.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Ejemplo Restricciones Tolerancia a Fallas

1Requerimiento de TF del subsistema

0Seguro ante Fallas (Sí)

- 1Uso Previo (Sí)

2 (SIL3) Tolerancia a Fallas Peligrosa minima

Grado de Tolerancia

a Fallas Peligrosa

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Probabilidad de Falla ante una Demanda - PFD

• PFD, qué es?

• Es una medida de la integridad de la seguridad de una SIF.

• Es un valor que indica la probabilidad de que un sistema falle en respuesta a una demanda, es incapaz de desempeñar la función de seguridad. La probabilidad promedio de un sistema que falla en respuesta a una demanda en un intervalo de tiempo especificado, se la denomina PFDavg.

• PFD es igual a 1 menos la Disponibilidad de Seguridad. Se la reconoce también como Indisponibilidad de la Seguridad.

• PFD = f (failure rate, repair rate, test interval, common cause, etc.)

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Probabilidad de Falla ante una Demanda

• El PFD de los sistemas puede ser determinado a partir de datos históricos. Cuando estos no están disponibles, puede obtenerse una evaluación sistemática del desempeño de un sistema utilizando técnicas de análisis de PFD.

• Las técnicas de análisis de PFD emplean metodologías sistemáticas que descomponen un sistema complejo en sus componentes básicos. El desempeño e interacciones de estos componentes básicos se fusionan en modelos de confiabilidad para determinar la disponibilidad general del sistema de seguridad.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Probabilidad de Falla Segura

• Para las SIF también se especifica una tasa de falla segura aceptable. Esta tasa también es comúnmente conocida como tasa de disparo falso o tasa de disparo espurio. La tasa de disparo espurio es incluida en la evaluación de la SIF porque, tanto la puesta en marcha como la parada del proceso, son los períodos donde las chances de ocurrencia de un evento peligrosos son altas. Entonces, en muchos casos, la reducción de la tasa de disparos falsos se expresa típicamente como el tiempo medio para disparo falso o MTTFspurious.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Determinación de PFD

• Para el cálculo de PFD están disponibles distintos métodos de modelado o análisis de confiabilidad. El método más apropiado es una decisión del analista y dependerá de las circunstancias.

• Entre los métodos disponibles (ver IEC 61508 – 6, Anexo B), se incluyen:

• Análisis Causa - Consecuencia

• Análisis Árbol de Fallas

• Diagramas en bloque de confiabilidad

• Ecuaciones simplificadas

• Modelos de Markov

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Análisis Árbol de Fallas

• Es un modelo gráfico de los caminos dentro de un sistema que pueden conducir a un evento peligroso predecible y no deseable. Los caminos interconectan eventos contribuyentes y condiciones, utilizando símbolos lógicos estándar. Las probabilidades numéricas de ocurrencia pueden ser entradas y propagadas a través del modelo para evaluar la probabilidad del evento peligroso predecible y no deseable.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Análisis Árbol de Fallas

• Los casos en que mejor se aplica son:

• Amenazas percibidas de grandes pérdidas, alto riesgo.

• Numerosos contribuyentes potenciales a un percance.

• Sistemas o procesos con múltiples elementos o complejos.

• Eventos no deseables ya identificados.

• Causas de percances indiscernibles.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Análisis Árbol de Fallas

• FTA es generalmente un procesos iterativo que envuelve el modelado de una SIF para determinar el PFD y las modificaciones necesarias de la SIF para alcanzar el PFD meta.

• El Análisis Árbol de Fallas puede describirse en 5 pasos esenciales:

• 1. Descripción de la SIF e Información de aplicación.

• 2. Identificación del evento tope.

• 3. Construcción del diagrama FTA.

• 4. Examen cualitativo de la estructura del árbol de fallas.

• 5. Evaluación cuantitativa del Árbol de fallas.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Análisis Árbol de Fallas - Resultados

• Descripción gráfica de la cadena de eventos/condiciones que conducen al evento tope.

• Identificación de los potenciales contribuyentes a fallas que son críticas.

• Mejor comprensión de las características del sistema.

• Penetración cualitativa/cuantitativa de la probabilidad de ocurrencia del evento seleccionado para el análisis.

• Identificación de los recursos comprometidos para prevenir la falla.

• Guía para el redespliegue de los recursos para optimizar el control de riesgos.

• Documentación analítica de los resultados.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Diagrama de bloques de confiabilidad

• El diagrama en bloques de confiabilidad puede ser pensado como un diagrama de flujo que va desde la entrada hasta la salida del sistema. Cada elemento del sistema es un bloque del diagrama y los bloques se colocan en relación con la arquitectura del SIS, para indicar que el camino desde la entrada hasta la salida se rompe si uno o más de los elementos falla.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Diagrama de bloques de confiabilidad

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Modelos de Markov

• El principio básico del Análisis de Markov es que un sistema puede existir en diferentes estados.

• Cada estado es definido por una falla interna del sistema. Usualmente, estas fallas internas están combinadas hasta un nivel que se llama estados del sistema.

• Estos estados están guiados por la disponibilidad de datos, por ejemplo, puede haber datos disponibles en el nivel placas de circuito impreso, pero también puede estar disponible en el nivel de transistores.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Modelos de Markov

• Independientemente del nivel de detalle, el sistema puede estar en los siguientes estados:

• Sistema totalmente operacional

• Sistema parcialmente fallado (degradado), pero todavía cumple con su función.

• Sistema totalmente fallado.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Modelos de Markov

• El Modelo de Markov es una buena herramienta para el análisis de confiabilidad de los sistemas EP debido a que el método es flexible y brinda un modelo realista. El modelo puede incluir, entre otros:

• Fallas de causa común

• Múltiples fallas

• Diferentes tiempos de reparación

• Tasas de falla variables

• El modelo de Markov es un diagrama de estados con círculos y flechas. Los círculos representan los estados del componente (operacional o fallado), las flechas muestran la dirección de las transiciones entre los estados (fallado o reparación), por lo que las flechas son arcos de dirección. Las tasas de falla o reparación representadas por las flechas con valores numéricos. Un modelo simple es el siguiente:

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� SEP - Modelo de Markov

• Modelo de Markov para un sistema 1oo1 que muestra los efectos de los distintos tipos de falla

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Ecuaciones Simplificadas

• La evaluación de un SIS, o de una porción de SIS, envuelve la estimación del PFDavg y del tiempo medio para un disparo falso o MTTFspurious de una SIF simple.

• Ambos factores pueden son importantes en la selección final y diseño del SIS.

• El PFDavg se determina calculando el PFD de todos los componentes de cada SIF que provee protección contra eventos peligrosos del proceso y combinando estos valores individuales se obtiene el valor de PFD de la SIF. Este valor se expresa con la siguiente fórmula:

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Ecuaciones Simplificadas

Procedimiento para la determinación del PFDavg de los sensores:

• 1. Identificar cada uno de los sensores que detectan las condiciones fuera de límite y que podrían conducir al evento contra el cual protege la SIF. Sólo aquellos sensoresque previenen o mitigan el evento designado son incluidos en los cálculos de PFD.

• 2. Liste la MTTFDU para cada sensor.

• 3. Calcule el PFD para cada configuración de sensor utilizando el MTTFDU y las ecuaciones en IEC 61508 Parte 6 con las consideraciones de redundancia que correspondan.

• 4. Sume los valores de PFD de los sensores para obtener el componente PFDS de la SIF que está siendo evaluada. Este paso sólo se requiere si la SIF incluye entradas de múltiples sensores.

• El componente PFD avg de la SIF correspondiente a los sensores combinados es:

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Ecuaciones Simplificadas

Procedimiento para la determinación del PFDavg para los elementos finales:

• 1. Identificar cada elemento final que protege contra las condiciones fuera de límites que pueden conducir al evento peligroso contra el cual nos protege la SIF. Sólo aquellos elementos finales que previenen o mitigan el evento designado son incluidos en los cálculos de PFD.

• 2. Liste la MTTFDU para cada elemento final.

• 3. Calcule el PFD para cada configuración de elemento final utilizando el MTTFDU y las ecuaciones en IEC 61508 Parte 6 con las consideraciones de redundancia que correspondan.

• 4. Sume los valores de PFD de los elementos finales para obtener el componente PFDA de la SIF que está siendo evaluada. Este paso sólo se requiere si la SIF incluye múltiples elementos finales.

• El componente PFDavg de la SIF correspondiente a los elementos finales combinados es:

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Ecuaciones Simplificadas

Procedimiento para la determinación del PFDavg para el procesador lógico es:

Nota. Puede ser provisto un sólo procesador lógico para múltiples SIF.

• 1. Identificar el tipo de hardware del Procesador lógico utilizado.

• 2. Seleccionar el MTTFDU para el procesador lógico (típicamente se obtiene del fabricante del procesador lógico).

• Nota. Puesto que el PFDavg del procesador lógico es una función no lineal, el usuario debería solicitar el MTTFDU para un número de intervalos de prueba funcional y utilizar aquellos que se ajusten a los requerimientos del sistema.

• 3. Calcular el PFDavg para la porción del procesador lógico asociado a la SIF utilizando las ecuaciones de IEC 61508 Parte 6 con las consideraciones de redundancia apropiadas. Nota. Este paso sólo se requiere cuando el fabricante no suministra el PFDavg para el sistema procesador lógico totalmente integrado)

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Ecuaciones Simplificadas

Procedimiento para determinar el PFDavg de la fuente de alimentación:

• Si el SIS está diseñado para desenergizar para disparo, la fuente de alimentación no tiene impacto sobre el PFDavg de la SIF debido a que una falla de la fuente de alimentación resultará en una acción que llevara al proceso a un estado seguro. Si el SIS está diseñado para energizar para disparo, el PFDavg de la fuente de alimentación se determina así:

• 1. Liste el MTTFDU para cada fuente de alimentación del SIS.

• Calcule el PFDavg para la fuente de alimentación utilizando las fórmulas de IEC 61508 Parte 6 con las consideraciones de redundancia apropiadas.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Ecuaciones Simplificadas

• Las ecuaciones simplificadas sin los términos que incluyen múltiples fallas durante la reparación, fallas de causa común y errores sistemáticos son las siguientes:

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Datos requeridos para confiabilidad

• Los modelos de confiabilidad nos permiten conocer el comportamiento de los sistemas de seguridad ante la presencia de fallas. Para realizar los cálculos necesitamos los siguientes datos:

• Tasa de Falla Total

• Porcentaje de fallas seguras

• Cobertura de diagnóstico – fallas peligrosas

• Cobertura de diagnóstico – fallas seguras

• Tiempo de reparación

• Intervalo de prueba de funcionamiento.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Cómo se obtienen los datos

• Debemos realizar un estudio de confiabilidad para la obtención de datos, especialmente de productos nuevos, incluyendo hardware electrónico, hardware mecánico y hardware electro-mecánico.

• El análisis típico es el FMEA: Análisis de Modo y Efectos de Falla

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Medidas de Control de Fallas

• Las fallas en los SIS, de acuerdo al momento en que se presentan, pueden clasificarse en

• Fallas que se originan antes o durante la instalación del sistema (fallas de software – especificación y programación - fallas de hardware – fabricación o incorrecta especificación.

• Fallas debidas a error humano que se originan después de la instalación del sistema (fallas aleatorias de hardware, fallas por uso incorrecto).

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Medidas de Control de Fallas

• La Norma IEC 61508 propone una serie de medidas para evitar o controlar esas fallas.

• En la IEC 61508 Parte 2, el Anexo A está dedicado a medidas de control de fallas durante la operación.

• En la IEC 61508 Parte 2, el Anexo B está dedicado a medidas para evitar fallas durante las distintas fases del ciclode vida de seguridad.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Medidas de Control de Fallas

depends on the quality of the comparison

highA.3.5Reciprocal comparison by software

highA.3.4Coded processing (one-channel)

mediumA.3.3Self-test supported by hardware (one-channel)

mediumA.3.2Self-test by software: walking bit (one-channel)

lowA.3.1Self-test by software: limited number of patterns (one channel)

depends on the quality of the voting

highA.1.4Majority voter

depends on the quality of the comparison

highA.1.3Comparator

NotesMaximum diagnostic coverage

considered achievable

SeeIEC

61508-7

Diagnostic technique/measure

Table A.4 — Processing units

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Medidas de Control de Fallas

• Table A.18 — Techniques and measures to control systematic operational failures

See table A.2 of IEC 61508-3 C.3.3Failure assertion programming

Rhigh

Rmedium

Rlow

Rlow

B.4.9Input acknowledgement

Rhigh

Rmedium

Rlow

Rlow

A.1.1Failure detection by on-line monitoring(see note 4)

HRmandatory

HRmandatory

HRmandatory

HRmandatory

B.4.8Modification protection

SIL4SIL3SIL2SIL1See IEC 61508-7

Technique/measure

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Medidas Para Evitar Fallas

• Table B.3 — Recommendations to avoid faults during E/E/PES integration

Rhigh

Rmedium

-low

-low

B.5.3Statistical testing

Rhigh

Rmedium

Rlow

Rlow

B.5.4Field experience

Rhigh

Rmedium

Rlow

Rlow

B.5.2Black-box testing

HRhigh

HRmedium

HRlow

HRlow

B.1.2Documentation

HRhigh

HRmedium

HRlow

HRlow

B.1.1Project management

HRmandatory

HRmandatory

HRmandatory

HRmandatory

B.5.1Functional testing

SIL4SIL3SIL2SIL1SeeIEC

61508-7

Technique/measure

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

�Diseño de Software

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Ciclo de Vida de Software

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Relación Hardware vs. Software

E/E/PES SRS

Hardware Electró-nico Programable

HardwareNo-programable

Hardware requerimientos de seguridad

Diseño y DesarrolloHardware Electrónica

Programable

Integración de PE(Hardware y software)

E/E/PES Arquitectura

SoftwareRequerimientos

de seguridad

Software DiseñoY Desarrollo

Alcance deParte 3

Alcance de Parte 2

E/E/PES Integración

Diseño y DesarrolloHardware No-Programable

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Prueba de Software

• Durante el diseño del software de aplicación se lo somete a diferentes pruebas con el propósito de eliminar errores que después inhiban al sistema de responder a una demanda.

• Las diferentes cuestiones que deben responderse son, al menos:

• La especificación es correcta?

• El programa desarrollado es correcto?

• Las pruebas realizadas son correctas?

• La prueba del software se realiza para tener un software seguro, es decir un software que permita al sistema de seguridad ejecutar las funciones de seguridad aún bajo condiciones de falla.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Prueba de Software

• Un software seguro se logra utilizando:

• Buenas prácticas de ingeniería e implementando un sistema de aseguramiento de la calidad.

• Utilizando un ciclo de vida para el desarrollo.

• Con una selección apropiada de medidas para evitar fallas. Por ejemplo, seguir las recomendaciones de las tablas A y B de la IEC 61508 Parte 3.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Modelo V

Test de Integración del Software de

Aplicación

TestSoftware Aplicación

E/E/PESEspecificación

Requerimientos de Seguridad

E/E/PESEspecificación

Requerimientos de Seguridad

Software Desarrollo.

DesarrolloMódulo

AplicaciónPrueba Módulo

Prueba de Validación

Prueba de Validación

SoftwareEspecificación

Requerimientos de Seguridad

SoftwareEspecificación

Requerimientos de Seguridad

ValidaciónSoftware Validado

E/E/PESArquitectura

Entrega

VerificaciónEntrega

Verificación

Software Arquitectura

Desarrollo y Prueba Código

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Modelo V

• La interpretación del Modelo V es la siguiente:

• Los elementos de la izquierda representan especificaciones, diseño y códigos.

• Los elementos de la derecha representan las distintas fases de pruebas y verificaciones.

• Se requiere que haya realimentación entre las fases.

• El diseño y las pruebas están asociadas a través de las actividades de verificación.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

�ARQUITECTURA de SIS

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Arquitectura de SIS

TOLERANTE A FALLAS

(FAULT TOLERANT)

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Configuraciones Tolerantes a Fallas

• SIS-LS con CPU doble y módulos de E/S dobles

• SIS-LS con CPU triple y módulos de E/S dobles o triples.

• SIS-LS TMR

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� CPU doble y módulos de E/S dobles

• Esquemático lógica de parada 2oo2

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� CPU doble y módulos de E/S dobles

• Esquemático lógica de parada 1oo2

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� CPU doble y módulos de E/S dobles

• Ejemplo 1oo2D Siemens Quadlog

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� CPU doble y módulos de E/S dobles

• Ejemplo 1oo2D Yokogawa ProSafe-RS

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� CPU triple y módulos de E/S triples

• Ejemplo 2oo3 TMR GE Fanuc

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� TMR – Modular Triple Redundante

• Esquemático 2oo3D SIFT TMR Triconex

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� TMR – Modular Triple Redundante

• Esquemático 2oo3D HIFT TMR Triplex

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Redundancia Modular Cuádruple

• Ejemplo 2oo4D QMR Honeywell Safety Manager

Ing. Qco. Roberto E. Varela ©

� Arquitecturas

SEGURO ANTE FALLAS

(FAIL-SAFE)

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Arquitecturas Seguras ante Fallas

• SIS-LS con CPU doble y módulos E/S simples

• SIS-LS con CPU doble y módulos E/S simples con diagnóstico

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� CPU doble y módulos E/S simples

• Esquemático 1oo1D Yokogawa ProSafe-RS

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� CPU simple y módulos E/S simples

• Ejemplo 1oo1D Siemens Quadlog

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� CPU doble y módulos E/S simples

• Ejemplo 1oo2D DMR Honeywell Safety Manager

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Acción ante Falla

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

�Operación y Mantenimiento

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� SIS – Criterios de Operación

• IEC 61511 contiene requerimientos relativos a operación, incluyendo planificación, procedimientos y entrenamiento de operadores.

• Por ejemplo, el operador debe estar entrenado en:

• Función del SIS: valor de disparo y acciones

• Peligros que el SIS está tratando de prevenir

• Operación de by-pass y cuando utilizarlos

• Medidas de compensación cuando el SIS está en by-pass

• Respuesta del operador a alarmas de diagnósticos

• Cuando y como el operador debe operar en manual

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� SIS – Criterios de Mantenimiento

• También incluye que debe hacerse cuando el SIS falla y como documentar el test y reparación de los dispositivos del SIS.

• Acciones de rutina para mantener la seguridad funcional

• Acciones para evitar situaciones peligrosas

• Procedimientos ante fallas o faltas

• Cuando se necesita un by-pass para test o mantenimiento

• Procedimientos para test prueba de funcionamiento

• Entrenamiento del personal

• Sistema de registro de mantenimiento

• Fallas seguras y peligrosas, reparaciones y causas raíz

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� SIS – Criterios de Mantenimiento

• Si hay más demandas que las asumidas en el diseño, debe revisarse el análisis de peligros y la evaluación de riesgos a fin de determinar si es necesario revisar el SIL seleccionado como meta

• Si los dispositivos del SIS tienen una tasa de falla mayor que la utilizada en los cálculos de diseño, debe hacerse una revaluación del PFD avg en base a los nuevos datos y deben implementarse modificaciones al SIS si es necesario.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� SIS - Test de Sistemas

• En las Normas IEC 61508 e IEC 61511 hay requerimientos bien claros para realizar pruebas de funcionamiento (tests), queincluyen a todos los componentes del SIS

• El test de los sistemas se efectúa por una sola y única razón, PARA DESCUBRIR LAS FALLAS ENCUBIERTAS! El test no previene la ocurrencia de disparos falsos. Ud. puede testear su sistema hoy, pero puede fallar mañana

• Lo que no está claramente explicado es la metodología para un óptimo test de cada dispositivo que forma parte de la función instrumentada de seguridad

• Cada SIS será inspeccionado visualmente en forma periódica para asegurar que no haya cambios no autorizados y no se observan deterioros físicos.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� SIS - Test de Sistemas

• Programa de Testeo• Debe incluir los siguientes objetivos

1. Procedimientos escritos para asegurar que los tests se realizan en forma segura y no generan un aparada inadvertida

2. La frecuencia estará determinada para asegurar la confiabilidad del sistema de seguridad. Tests muy frecuentes generan costos innecesarios, pocos tests pueden resultar en un incidente peligroso

3. Las aplicaciones que requieran test en línea tendrán el diseño apropiado incluyendo by-pass, para asegurar el punto 1

4. Tests fuera de línea son fáciles de manejar pero tienen los mismos requerimientos de documentación y frecuencia que los que se realizan en línea

5. Todo el programa de testeo debe ser revisado anualmente para determinar si la frecuencia es adecuada y/o se necesita realizar modificaciones

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Instalación y Comisionado

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Instalación y Prueba Mecánica

• Todo el equipamiento debe instalarse según planes de diseño e instalación

• Cualquier modificación requiere el retorno a la fase apropiada del ciclo de vida

• Las actividades de prueba mecánica incluyen:• Equipos y cableado instalados correctamente• Fuentes de energía operacionales• Todos los instrumentos están calibrados• Sensores y actuadores operacionales• Procesador lógico y E/S operacionales• No hay daños físicos visibles

• Previo a la puesta en marcha debe realizarse un verificación funcional o test de aceptación (SAT)

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

�Validación

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Validación

• Mediante el proceso de Validación lo que hacemos es verificar que hemos instalado el sistema adecuado.

• Validamos lo especificado, en base a la especificación de Requerimientos de Seguridad.

• Plan de Validación

• Pruebas en Fábrica (FAT) y en el Sitio (SAT)

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Administración del Cambio (MOC)

• Requerida para:• Modificaciones de procedimientos operativos• Modificaciones al proceso• Modificaciones al software

• MOC debe contener• Bases técnicas para los cambios propuestos• Impacto sobre la salud y el ambiente• Procedimientos para la Autorización

• Revisión de los cambios requeridos• Personal afectado debe ser notificado• Los cambios deben realizarse a partir de la fase

del ciclo de vida apropiada

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Administración del Cambio (MOC)

• Las modificaciones al sistema deben ser ejecutadas siguiendo lasmismas estrictas reglas que fueron utilizadas para el diseño original del SIS. El procedimiento a seguir es el siguiente:

Solicitud de Modificación

Estudio Análisis de Impacto

Informe Análisis de Impacto

Autorización

HAZOP

A Fase apropiada del Ciclo de Vida

Desempeño del sistema por debajo de metas

Fallas SistemáticasIncidentes / Accidentes

Solicitud OP / MANTCambios en legislaciónModificaciones en EBCCambios en SRS

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Desinstalación

• Realice una revisión previa apropiada antes de poner fuera de servicio al SIS

• Asegúrese que otras unidades de proceso no estarán afectadas

• Requiere de un plan de Administración para el Cambio debidamente autorizado

• Aplicación de los pasos del Ciclo de Vida, incluyendo Evaluación de Riesgos

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

�Certificación

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Certificación

• Organizaciones como TÜV Rheinland y TÜV Product Service, entre otras, realizan la certificación de sistemas para uso en aplicaciones de seguridad, en un todo de acuerdo a las normas de seguridad publicadas por IEC, DIN, etc.

• Estas entidades no escriben normas, solo certifican equipos según la norma que se seleccione. Todas pueden realizar evaluaciones simultáneas de productos según normas IEC, DIN y ANSI/ISA, determinando los niveles AK y SIL. Por ejemplo, TÜV Rheinland certificó durante muchos años equipamiento de control para ser utilizado en seguridad, utilizando las normas alemanas

DIN V 19250/05.94

DIN V VDE 0801/01.90 with amendment A1: 1994-10

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Certificación

• Los certificados expedidos por TÜV le aseguran al usuario final que los componentes y/o subsistemas certificados fueron evaluados por una agencia de aprobación independiente, respecto de los requerimientos expresados en las normas de aplicación.

• El conjunto de normas utilizados para la certificación consta en el certificado expedido.

• El certificado muestra, también, que los componentes o subsistemas pueden se utilizados en aplicaciones específicas de acuerdo a la Clase de Requerimiento (RC) o al Nivel de Integridad (SIL)

• El usuario final debe estar en conocimiento de cómo utilizar el componente o subsistema en funciones relacionadas con seguridad.Debido a las distintas posibilidades existentes para configurar un sistema e seguridad dado, el usuario final debe obtener la información correspondiente de parte del fabricante del sistema.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Certificación – Probado en Uso – IEC 61508 - 2

• Un subsistema desarrollado previamente, será visto como “probado en uso” cuando haya evidencia documental adecuada basada en el uso previo de una configuración específica del subsistema (durante el tiempo de uso se han registrado formalmente todas las fallas y toma en consideración cualquier análisis o test adicional, según se requiera).

• La evidencia documental demostrará que la probabilidad de cualquier falla de un subsistema (debido a fallas aleatorias de hardware y sistemáticas) de un sistema E/E/PE relacionado con seguridad, es lo suficientemente baja de manera tal que el nivel de integridad de la seguridad requerido para la función de seguridad que utiliza el sistema, es alcanzado.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Certificación – Probado en Uso – IEC 61508 - 2

• La evidencia documental demostrará que las condiciones previas de uso de un subsistema específico son las mismas que, o lo suficientemente cerca de, aquellas que serán experimentadas por el subsistema como parte de un sistema E/E/PE relacionado con seguridad, en orden de poder determinar que la probabilidad de una falla sistemática no revelada es tan baja, que el nivel de integridad de la seguridad de la función de seguridad que utiliza el subsistema es alcanzado.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Certificación – Probado en Uso – IEC 61508 - 2

• De acuerdo a antecedentes existentes deben cumplirse los siguientes puntos:

• Especificación sin cambios;

• 10 sistemas operando en diferentes aplicaciones;

• 10*E5 horas de operación y por lo menos un año de historia de servicio.

• La experiencia de campo es demostrada por la documentación suministrada por el proveedor y/o fabricante u operador. La documentación incluirá como mínimo:

• La designación exacta del sistema y sus componentes, incluyendo

• Versión de control del hardware;

• Usuarios y tiempo de aplicación;

• Horas de operación;

• Los procedimientos para la selección de los sistemas y aplicaciones en los que se llevan a cabo las pruebas;

• Registro de detección y remoción de fallas.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Certificación – Uso Previo – IEC 61511 - 1

• Requerimientos para la selección de componentes y subsistemas en base a uso previo:

• Evidencia apropiada deberá estar disponible demostrando que los componentes y subsistemas son adecuados para uso en un SIS.

• NOTA 1 En el caso de elementos de campo, hay gran experiencia operativa tanto en aplicaciones de seguridad u otras. Esta información puede ser utilizada como base para la evidencia.

• NOTA 2 El nivel de detalle de la evidencia debería estar de acuerdo con la complejidad del componente o subsistema considerado y con la probabilidad de falla necesaria para alcanzar el nivel de integridad de la seguridad de la función instrumentada de seguridad.

• La evidencia de adecuación incluirá lo siguiente:• Consideración de la calidad del fabricante, su administración y del sistema de gestión

de la configuración

• Adecuada identificación y especificación de los componentes o subsistemas

• El volumen de experiencia operativa

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Certificación – Uso Previo – IEC 61511 - 1

• Requerimientos para la selección de componentes y subsistemas programables FPL (por ejemplo, dispositivos de campo) en base a uso previo

• Requerimientos para la selección de componentes y subsistemas programables LVL (por ejemplo, procesadores lógicos) en base a uso previo

• Requerimientos para la selección de componentes y subsistemas programables FVL (por ejemplo, procesadores lógicos)

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Certificación – Cumplimiento de Normas IEC 61508/IEC 61511

• El cumplimiento de los requerimientos de la norma y la certificación de una entidad independiente facilita el diseño del sistema y lo hace más económico

• Los certificados de terceros no son garantía de que los productos pueden ser utilizados en todas las aplicaciones de seguridad. En el reporte del Certificador o en el manual de Seguridad del fabricante deben estar listadas las restricciones de uso.

• El subsistema cumple con los requerimientos cualitativos correspondientes al nivel de integridad de la seguridad de la función instrumentada de seguridad

• Procedimientos para el desarrollo del diseño han sido escritos y son seguidos.

• Los requerimientos técnicos de la norma están implementados en el subsistema.

• El subsistema tiene definida una probabilidad de falla ante una demanda máxima (PFDAVG) para la función de seguridad.

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Certificación

• Para más información sobre los sistemas certificados por TÜV, consultar en

http://www.tuv-fs.com/index.htm

http://www.tuvasi.com

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

�Sumario Selección de SIS

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Recomendaciones para Usuarios

1. Adopte IEC 61511

2. Análisis de Peligros y Evaluación de Riesgos en Proceso para decidir cuál es el mejor método para proteger su planta

3. Adicione capas de protección no-SIS en lo posible

4. En base a la Evaluación de riesgos seleccione el SIS certificado, por un ente confiable, que mejor cumpla sus necesidades

5. Elija el SIS que mejor se integre con sus sistema de control, pero manteniendo el grado de separación requerido por las normas.

6. Elija el sistema que provea una solución de seguridad integrada desde el sensor hasta la válvula de control.

7. Monitoreo continuo del equipamiento de campo y tests periódicos

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Recomendaciones para Usuarios

8. Seleccione un sistema que maximice la seguridad a la vez que maximice, simultáneamente, la disponibilidad, a través de tests automáticos y diagnósticos extensos.

9. Diseñe seguridad dentro del proceso

10. Asegúrese que el diseño conceptual cumple con los requerimientos de desempeño

11. Documente todos los procedimientos

12. Solicite a su proveedor el Manual de Seguridad que incluye las restricciones de uso

13. Siga los procedimientos para la Administración de Cambios

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Bibliografía

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

� Bibliografía

• IEC 61508 Parts 1 to 7 - (1999-05) Functional safety of electrical/electronic/programmable electronic safety-related systems.

• IEC 61511 Parts 1 to 3 - Edition 1.0 (2003 – 12) Functional Safety – Safety Instrumented Systems for the process industry sector

• Safety Instrumented Systems: Design, Analysis, and Justification - ISA publication, 2nd Edition, 2004Paul Gruhn, P.E., CFSE and Harry L. Cheddie, P.Eng., CFSE

• Análisis y reducción de riesgos en la industria química - J. M. Santamaría y P.A. Braña. Ediciones FundaciónMAPFRE, España, 1994

• Are your instrumented safety systems up to standard? - Kimberly A. Ford and Angela E. Summers, Ph.D, Sis-Tech Solutions.

• Dual vs. Triple - Paul Gruhn, Siemens Energy & Automation, May 2000

• Separation – control and safety - William M. Goble, Vol. 79 No. 8 Automation Safety, August 2000

• Fail safe or fault tolerant? - Russell Cockman, September 2000

• 2oo4D: Nueva generación de sistemas de seguridad Honeywell S.A.I.C., Revista Instrumentación y Control Automático, Número 109, Buenos Aires, Argentina.

• Sistemas Instrumentados de Seguridad – Evolución, diseño y aplicación – Ing. Qco. Roberto E. Varela –Editoral Soluciones en Control . Buenos Aires – 2003

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©

“It should not be necessary for each generation to rediscover principles of process safety which the generation before discovered.

We must learn from the experience of others rather than learn the hard way.

We must pass on to the next generation a record of what we have learned.”

Jesse C. Ducommun - Safety PioneerAmoco Oil Vice-president of Manufacturing 1955

MARZO 26, 2007Ing. Qco. Roberto E. Varela ©