Maestría: MANTENIMINETO E

INSTRUMENTACION EN PLANTAS DE GAS

Maestría: OPERACIONES PETROLERAS
Diplomado: INSTRUMENTACION Y
CONTROL EN PLANTAS DE PROCESOS

Sistemas Instrumentados de Seguridad

12. Diseño del Hardware Docente: Ing. Nelson Yañez

Correo: nelson@cotas.com.bo

www.inegas.edu.bo 1
2
Conceptos Fundamentales del Hardware
El diseño de hardware a nivel de la función de
seguridad:
 Energizar versus des-energizar para disparar
 Baja demanda, alta demanda, modo continuo
- 61508
 Modo demanda, modo continuo - 61511
 Probabilidad de Falla en Demanda (PFD)
Una medida del Safety Integrity Level (SIL)
 Probabilidad de Falla Segura (PFS)
Una medida del Spurious Trip Level® (STL)

3
Des-energizar o Energizar para Disparar

Cuál es la diferencia?
 Un sub-sistema "des-energizar para
disparar" no necesita energía para ejecutar
su función de seguridad
Se basa en el así llamado "principio de
diseño falla - segura"
 Un sub-sistema "energizar para disparar"
necesita energía para ejecutar su función
de seguridad
Éste no es un diseño falla - segura

4
Ejemplos: "Des-energizar para disparar"
Logic solver "fail - safe"
 El estado seguro es siempre el
estado "O". o estado des-
energizado
 Sólo con energía eléctrica
resultará el estado "1”.
Actuador con retorno a resorte
 Energizar el resorte para abrir la
válvula
 Des-energizar el resorte para
cerrar
 Diseño fail - safe
5
Ejemplos: "Energizar para disparar"
Sistema de "sprinklers"
 Bombas
 Electricidad
 Agua

Sistema Fire & gas

 Detección y
 Gestión de alarmas

6
Baja Demanda, Alta Demanda, Continuo

lEC 61508 define tres modos de

operación para las funciones de
seguridad

 Modo de Baja Demanda

 Modo de Alta demanda
 Modo Continuo

7
Modo de Baja Demanda - lEC 61508
Función de seguridad de
baja demanda
 Cuando la función se
ejecuta ante una
demanda, para llevar al
equipo bajo control a un
estado seguro y cuando
la frecuencia de esta
demanda no es mayor a
una demanda por año
 Ejemplo típico
Función de shutdown
con válvula ESD
8
Modo de Alta Demanda - lEC 61508
Función de seguridad de alta
demanda
 Cuando la función se
ejecuta ante una demanda,
para llevar al equipo bajo
control a un estado seguro
y cuando la frecuencia de
esta demanda es mayor a
una demanda por año
Ejemplo típico
 Función de shutdown con
válvula de drenaje en un
reactor de procesos

9
 Modo Continuo - lEC 61508
Función de seguridad de modo
continuo
 Cuando la función retiene,
al equipo bajo control en
un estado seguro como
parte de la operación
normal.
Ejemplo típico
 Función que regula un
caudal de alimentación de
un producto a un reactor,
cuya variación puede
ocasionar una reacción
fuera de control
También se las conoce como
funciones de Control Crítico
10
Modo Demanda VS. Continuo - lEC 61511
lEC 61511 define los modos demanda y continuo
Modo demanda
 La falla de la función de seguridad, por sí misma, no tiene
un efecto inmediato en el proceso
 El proceso está en peligro si
La función de seguridad ha fallado Y

Ocurre una demanda

Modo continuo
 Una falla de la función de seguridad, por sí misma, tiene
un efecto inmediato en el proceso
 El proceso está en peligro por el sólo hecho de que la
función de seguridad ha fallado en forma peligrosa

11
Precaución

La razones de cada demanda necesitan ser

analizadas
 Un mal control del proceso resulta a menudo
en demasiadas demandas
 Demandas frecuentes en un proceso de baja
demanda no debieran resultar,
necesariamente, en "lo que necesitamos es
un sistema de alta demanda"
 Podrían resultar cambios en el diseño, o en la
operación del proceso, o cambios en los
procedimientos, etc.

12
Probabilidad de Falla
Para cada función de seguridad se necesita saber cuán
a menudo ésta falla
 Probabilidad de Falla en Demanda - PFD
La probabilidad de que la función de seguridad no
se ejecute al recibir una demanda del proceso
Requerimiento en lEC 615611
 Probabilidad de Falla Segura - PFS
La probabilidad de que la función de seguridad se
ejecute sin que haya una demanda desde el
proceso
No es un requerimiento en lEC 61561 1
Sin embargo indica que quizá deba tenerse en
cuenta

13
PFDavg versus PFH

La probabilidad de falla en demanda después de un

año o después de una hora

14
Spurious TriP Level® - STL

La Probabilidad de Falla Segura - PFS

15
Cómo usar el Spurious Trip Level®
Para cada función de seguridad, estime el costo de un
disparo espurio
Cuanto mayor sea el costo más alto deberá ser el STL
Los niveles necesitan ser determinados para cada
compañía en particular. Vea un ejemplo más abajo.

16
 Sub-sistemas
Una función de seguridad es parte de un sistema el
cual puede tener varios subsistemas y elementos
Todos éstos deben ser ítems conforme a norma, es
decir, que deben cumplir con todos los requerimientos
de la norma.

17
Conceptos Fundamentales del Hardware
Diseño del Hardware a nivel de sub-
sistemas
 Redundancia y diversidad
 Votación y Tolerancia a Fallas del
Hardware (HFT)
 Tipo A y Tipo B
 Modos de falla
 Fallas detectadas y reveladas
 Fracción de Falla Segura (SFF)
 Restricciones de arquitectura
18
Redundancia

Definición:
 El uso de múltiples medios para conseguir
la misma (o PARTE DE la misma) función de
seguridad
La redundancia puede conseguirse
 Por igual hardware y/o software o
 Por diversidad de hardware y/o software
No ayuda necesariamente contra las fallas de
causa común y no ayuda contra las fallas
sistemáticas

19
Ejemplos de redundancia

Equipamiento redundante

Bus de comunicación simple con mensajería

triple redundante

20
Diversidad

Definición:
 El uso de diferentes medios para ejecutar
la misma (o PARTE DE la misma) función
de seguridad
Puede conseguirse por
 Diferentes métodos físicos
 Diferentes filosofías de diseño
Es una medida contra las fallas de causa
común y sistemáticas, pero no
necesariamente ayuda contra todas ellas

21
Ejemplos de diversidad

22
Votación
Votación es
 El número de caminos independientes (M)
requeridos dentro del total de caminos
eXistentes (N) para poder ejecutar la función
de seguridad
La votación se expresa normalmente como
MooN
 M expresa el número de votación
 N expresa el número de redundancia
 Por ejemplo 1002, 2003, 2004, etc .
La votación puede "destruir" la redundancia
 Por ejemplo: 2002
23
Ejemplos - MooN

24
Tolerancia a Fallas del Hardware (HFT)

Una tolerancia a fallas de hardware 'N '

significa
 Que N + 1 fallas pueden causar la pérdida
de la función de seguridad
La HFT es fácil de calcular
 Para cualquier sistema MooN: HFT =N - M
 Por ejemplo, la HFT de un sistema 2003
es: 3 - 2 = 1

25
Sub-sistemas Tipo A
Un sub-sistema es Tipo A si:
 Los modos de falla están bien definidos Y
 La conducta durante una falla puede ser
determinada completamente Y
 Se hallan disponibles suficientes datos de
falla

26
Sub-sistemas Tipo B

Un sub-sistema es Tipo B Si:

 Una o más modos de falla no
están bien definidos, O
 Si la conducta ante una falla
no puede ser completamente
definida, O
 Si los datos de falla
disponibles no son suficientes
 Si tiene algún circuito
integrado puede estar 99.9%
seguro de que es Tipo B

27
Modos de Falla de los Sub-sistemas
Falla Segura
 El sub-sistema falla en forma segura, si éste ejecuta la
función de seguridad sin que haya una demanda desde el
proceso
Falla Peligrosa
 El sub-sistema falla en forma peligrosa, si éste no puede
ejecutar la función de seguridad ante una demanda
Falla de No Efecto
 El elemento que falla es parte de la función de seguridad,
pero la falla no afecta a esta función
Falla de No Es Parte
 El elemento que falla no es parte de la función de seguridad
Falla Detectada
 Una falla es "detectada" si los diagnósticos incorporados
(built- in) la descubren
28
Descubriendo Fallas

Las fallas pueden ser descubiertas de tres

formas:
 Durante la operación normal
 Mediante pruebas manuales periódicas
 Periodic Proof Tests
 Por medio de diagnósticos incorporados
(built-in)
 Diagnostic Tests

29
Por medio de la Operación Normal del proceso
Descubrirlas durante la operación normal
significa que la conducta propia del proceso, por
sí misma. revela la falla del sub-sistema, por
ejemplo,
 El proceso se detiene debido a una falla
segura en un transmisor de presión, o
 El tanque no se puede vaciar debido al
peligroso bloqueo en cerrado de la válvula de
drenaje
 Este forma de descubrir fallas no es útil
 Ni desde el punto de vista de la seguridad
 Ni desde el punto de vista de la disponibilidad
30
Descubriendo Fallas por medio de Pruebas
 En los sistemas de seguridad se llevan a cabo muchas
pruebas (testing)
Pruebas manuales periódicas (Periodic Proof Tests)
Pruebas de diagnóstico (built-in Diagnostic Tests)
 Cualquiera de estas pruebas comprende
Frecuencia: Cuán a menudo se la real iza
Cobertura: El porcentaje de fallas detectadas
 Una prueba es útil sólo si se actúa de acuerdo con sus
resultados, por ejemplo:
Llevando inmediatamente el sistema a condición
segura
No permitiendo que el sistema vuelva a arrancar si
la falla no fue reparada
31
Descubriendo Fallas por Diagnóstico

 Una prueba es de diagnóstico (Diagnostic Test) si:

Se ejecuta en forma automática Y
Se ejecuta frecuentemente Y
Se utiliza para descubrir fallas que puedan hacer
peligrar la función de seguridad y
Resulta en una respuesta segura
 Usualmente una prueba es de diagnóstico y está
incorporada ("built-in")
Por ejemplo un test de memoria, el "watchdog",
etc.

32
Acerca de la Frecuencia de Diagnóstico
 Con qué frecuencia debería ejecutarse una prueba
llamada "Diagnostic Test"?
Por lo menos un orden de magnitud mayor que la
"tasa de demanda" esperada
Frecuencia de DT > 10* Frecuencia de Demanda
Estimada
 Por ejemplo
Si la demanda esperada es 1 vez por año, y se realizan
pruebas automáticas de 'partial stroke’ más de una
vez por mes, entonces esas pruebas de "partial
stroke' son consideradas como "Diagnostic Test"
Las mismas pruebas automáticas de "partial stroke"
realizadas cada 2 meses, deben ser consideradas
como Periodic Proof Test

33
Descubriendo Fallas por Pruebas Periódicas

 Todas las otras pruebas son llamadas Pruebas

Periódicas (PPT = periodic proof test). Éstas son:
NO automáticas O
De muy baja frecuencia
 Una prueba periódica
Es iniciada por la acción humana
Usualmente no está incorporada ("built-in'') en el
equipamiento. Se requiere equipamiento adicional
para ejecutarla
Por ejemplo, un operador realiza la prueba de
cierre parcial (partial stroke test) de una válvula

34
Pruebas Periódicas (PPT)

 Podemos ejecutar una Prueba Periódica

 En un dispositivo individual
 En una combinación de dispositivos
 En la función de seguridad completa

35
Diferencias entre DT y PPT

36
Distribución de Fallas

37
Detectada o No Detectada

38
Fracción de Falla Segura (SFF)

 Qué es la SFF?
 Una medida de la efectividad del diseño
"failsafe” y/o de los diagnósticos incorporados
de un sub-sistema
 Es un parámetro de diseño, no un parámetro
operacional
 Se calcula como:

39
Atención
 No se puede utilizar una Prueba Periódica (PP1) para
calcular la SFF
Prueba Periódica (PPT) es un parámetro operacional
 Por qué existe la SFF?
La PFD refleja cuán a menudo un sub-sistema falla en
forma peligrosa no detectada
Esto no es suficiente para expresar la seguridad
 La DU es la proporción de fallas peligrosas no detectadas
inherentes a un sub-sistema %DU=1-SFF (Fallas
peligrosas no detectadas)
SFF "qué porcentaje"
PFD "qué tan probables"

40
Restricciones de Arquitectura
(lEC 61508 - Ruta 1H)

41
 Restricciones de Arquitectura (lEC 61511)

 Programmable electronic (PE) logic solvers

42
Restricciones de Arquitectura
(lEC 61151-1)

 Todo equipamiento excepto los PE logic solvers

43
¿Cuándo reducir o incrementar la HFT?

 Podemos reducir en "1" la HFT

Si el dispositivo está seleccionado como
"prior use" Y
Sólo pueden ajustarse parámetros
relacionados con el proceso Y
Este ajuste de parámetros está protegido Y
El SIL es menor que 4
 Debemos aumentar la HFT en "1"
 SI la falla dominante no lleva al sub-
sistema a un estado seguro Y
 No pueden detectarse las fallas peligrosas

44
¿Cuándo lEC 61508 Y cuándo lEC 61511?

45
Integridad de la seguridad del hardware: restricciones de la
arquitectura en el tipo A y B en subsistemas relacionados con la
seguridad

46
¿Restricciones de Arquitectura
Insatisfechas?

Deténgase!
 No hay necesidad de continuar
 No hay necesidad de hacer cálculo de
probabilidades
Lo que usted necesita hacer es
 Rediseñar la arquitectura O
 Cambiar la configuración de la arquitectura
Seleccionar dispositivos más apropiados
Seleccionar dispositivos con una SFF mayor

47
Sistema de Seguridad 1001

48
Sistema de Seguridad 1001 versión II

49
Sistema de Seguridad 1002

50
Sistema de Seguridad 1002 versión II

51
Sistema de Seguridad 11002 versión IV

52
Sistema de Seguridad 2002
• Mal diseño de sistema de seguridad
Ninguna Seguridad -> Disponibilidad de
Proceso

53
Análisis de Confiabilidad

Por qué un Análisis de Confiabilidad? De

acuerdo con la Normas, necesitamos
 Documentar el comportamiento de la fal la
de la función de seguridad
 Determinar la SFF para cada sub-sistema
 Determinar la "PFD Objetivo" (PFDavg, PFH)
para cada función de seguridad
Otra razón para realizar un estudio de
confiabilidad
 Los Usuarios también quieren saber las tasas
de falla espurias de la función de seguridad

54
Pasos del Análisis de Confiabilidad

55
Diagrama de Bloques Funcionales
Cree el diagrama de
bloques funcionales
 Desde el punto de vista
del funcionamiento (sin
fallas)
Tome en cuenta relaciones
funcionales
 Descienda hasta el
componente reparable
más pequeño (módulo)
Tome en cuenta la
redundancia y la votación

56
Diagrama de Bloques Funcionales

57
Ejemplos de Ecuaciones lEC 61508-6

• 1001

• 1002

La lEC 61508 tiene fórmulas para bloques de

confiabilidad con votaciones 1001, 1002,
1002D, 2002, y 2003
Estas fórmulas no son normativas
Las ecuaciones simplificadas se pueden
derivar de modelos de Markov
58
Modelos de Confiabilidad

59
Confiabilidad vs. Disponibilidad
 Disponibilidad (Availability) – La probabilidad de
éxito en un momento en el tiempo
A = f( λ , μ ) (Tasa de falla y tasa de reparación)
 Confiabilidad (Reliability) – La probabilidad de éxito
durante un intervalo de tiempo
R = f( λ, TI = t ) Tasa de falla, intervalos de tiempo
La confiabilidad y la disponibilidad son frecuentemente
intercambiados. Ellas son medidas similares de una
operación exitosa. La disponibilidad es por su lado un
valor promedio que es una función de las tasas de falla
y de las tasas de reparación. La confiabilidad es una
función de las tasas de falla y de los intervalos de
tiempo de operación.

60
Ejemplo - Disponibilidad

 Tasa de Falla – Falla por unidad de tiempo por dispositivo

 Mean Time to Failure (MTTF) – Tiempo promedio a la falla
– El intervalo tiempo promedio de operación exitosa de un
sistema (puede ser extendido a sub sistemas o
dispositivos)
 Mean Time to Repair (MTTR) – Tiempo promedio de
reparación – El intervalo de tiempo de reparación
promedio de un sistema. Aplica solo a sistemas reparables!

Debe tenerse cuidado con el término MTTR que no es universalmente

definido a través de varias normas internacionales y los libros de texto
de ingeniería de confiabilidad.

En la IEC 61508 por ejemplo, es el acrónimo de “Mean Time to Restore”.

61
www.inegas.edu.bo
62