1. INTRODUCCION
1.1. Independencia de funciones
La combinación de los sistemas de control especifico y los sistemas relacionados con la seguridad es un tema discutido, la independencia de estos sistemas, reducen la posibilidad de que ambos no realicen su función al mismo tiempo y, por ello, consideremos aquí una independencia total entre función de control especifica y función de control de la seguridad.
1.2. Distribución de requisitos
Un subsistema es una parte de un sistema que desarrolla una función especializada. En los sistemas E/E/EP podemos de manera simple separar un sistema en tres subsistemas: Sensores, procesador lógico y elementos finales de control (actuadores).
Las tareas a llevar a cabo en esta fase son:
2. DISTRIBUIR LOS REQUISITOS GLOBALES RAMS DEL SISTEMA
El proceso para distribuir los requisitos globales RAMS del sistema seran:
Podemos simplificar, despues de separar el sistema de seguridad, diciendo que para asegurar el cumplimiento del SIL cada sistema se compone de (al menos) 3 subsistemas:
En este caso simplificado la PFDavg del sistema, sera:
PFDsist.= PFDs + PFDl + PFDa
PFDs = Probabilidad de falla en demanda del sensor
PFDl = Probabilidad de falla en demanda del procesador logico
PFDa = Probabilidad de falla en demanda del actuador.
Sistemas redundantes (Arquitecturas redundantes)
En sistemas de arquitectura redundante, la probabilidad de falla en demanda la podemos generalizar como:
PFDsis = ∑PFDs + ∑PFDl + ∑PFDa + ∑PFDss + ∑ PFDps
donde:
PFDss es la probabilidad de falla de causa común.
PFDps es la probabilidad de falla de la fuente de alimentación.
Para las configuraciones típicas usadas en seguridad (denominadas 1oo1, 1oo2 y 2oo3)
La obtencion del valor de λdu (tasa de fallas peligrosas no detectadas:
λdu = 1/ MTTFdu
donde MTTFdu es el tiempo medio entre fallas.
La tasa de fallas de causa comun (λcc) se calculara como
λcc = λdu * β
Siendo β el factor de causa comun.
Configuración 1oo1
PFDavg= [λdu* TI/2]+ [λs* TI/2]
donde
λdu es la tasa de fallas peligrosas no detectadas
λs tasa de fallas sistematicas
TI intervalo entre test de pruebas funcionales
[λs* TI/2] es la probabilidad de falla debido a errores sistematicos.
Conciertas consideraciones de diseño pueden llevar a simplificar estas funciones hasta poder definir la probabilidad de falla como
PFDavg = [λdu * (TI/2)]
Configuración 1oo2
Siendo:
MTTR el tiempo medio de reparación
Β el factor de causa común, fracción de fallas que impactan en mas de un canal en un sistema redundante
[λdu * λdd * MTTR * TI] representa la probabilidad de errores durante el tiempo de reparación de uno de los elementos de un canal, esto se puede considerar nulo si el tiempo de reparación es corto (ejemplo < 8 hs)
El termino [β * λdu * (TI/2)] es la probabilidad de fallas debido a fallas de causa común
El termino [λs* (TI/2)] es la probabilidad de fallas debido a errores sistemáticos
Otras Configuraciones
2.1. Sensores.
En general son usados para medir parámetros, pueden ser discretos o o analógicos y dan una salida variable relacionada con otra variable de un proceso.
Existen dos categorías de fallas asociadas a un sensor: a) fallas seguras (fail-safe) que podría ocasionar una parada no esperada del sistema y b) fallas peligrosas.
El sistema debería diseñarse para que operen el modo fail-safe, esto quiere decir que cualquier anomalía en la función de seguridad no lleve a una situación peligrosa.
A los efectos de reducir la PFDs debemos diagnosticar los sensores. Las siguientes formulas muestran el impacto del diagnostico de fallas en el probabilidad de fallas peligrosas:
λdd = λd * DCd
λdu = λd * (1 - DCd)
λd = λdd + λdu
DCd = Factor de cobertura de diagnostico de fallas peligrosas.
λd = tasa de fallas peligrosas λ= tasa de fallas seguras
λdu = tasa de fallas peligrosas no detectadas λsu= tasa de fallas seguras no detectadas
λdd= tasa de fallas peligrosas detectadas
λsd= tasa de fallas seguras detectadas
Si incrementamos el factor de cobertura, decrece la tasa de fallas peligrosas no detectadas. ATENCIÓN la tasa de fallas peligrosas no cambia con el diagnostico, solo que son mas las fallas detectadas.
Otro parámetro muy utilizado para indicar la efectividad del diagnostico es la fracción de falla segura (SFF). Este parámetro se puede determinar para cada elemento del sistema (sensor, actuador, lógica) como
SFF = (λsd + λsu + λdd) / (λsd +λsu + λdd + λdu)
2.2. Actuadores (Elementos finales de control)
Los elementos finales de control son utilizados para alcanzar un estado seguro del sistema o una para segura. Estos elementos son responsables de un alto porcentaje de fallas ya que son (en su mayoría) elementos mecánicos que se desgastan.
2.3. Programador lógico
Los sistemas tipo "E", eléctricos basado en reles, se utilizan en sistemas muy pequeños, son seguros y no están afectados por la mayoría de las interferencias, con ellos se puede alcanzar un nivel SIL 3. Entre sus inconvenientes tenemos que son muy complejos para grandes sistemas, el cambio de lógica es manual y requiere modificaciones al cableado, no existe posibilidad de comunicaciones con otros sistemas, solo admite señales digitales, entre otros inconvenientes.
Los sistemas "E" electronicos de estado solido, no utilizan softwre, si bien se usan en pequeños sistemas ya comenzaron a entrar en desuso. Estos sistemas tienen posibilidad de comunicación, son rapidos. Entre sus inconvenientes tenemos alta complejidad, logica binaria y alto costo.
Los sistemas "EP" son sistemas electrónicos programables (basados en software), entre sus ventajas tenemos un costo razonable, flexibilidad para hacer cambios, fácil documentación, interfaz con el operador. Entre sus problemas tenemos que la CPU puede dejar de ejecutar el programa, las entradas y saldas dejan de manejar valores reales, fallas en la memoria.
Al momento de definir (comprar - desarrollar) un sistema programable de seguridad se debe poner atenciaon a: nivel de SIL, tiempo maximo del ciclo, arquitectura del sistema, tiempo de respuesta, configuración de I/O, acceso limitado a conexiones externas.
Respecto del software, tenemos tres tipos: de aplicacion, de servicios y embebidos. El primero es donde se desarrolla la SIF por lo cual debe cumplir con el ciclo de vida de seguridad, los dos ultimos estan regulados para aplicaciones de seguridad en la IEC 61508.
Un software de seguridad ha de ser desarrollado de tal forma que logre: modularidad y funcionalidad, facilidad para probar la funcionalidad, posibilidad de realizar pruebas seguras, el diseño debe ser robusto, los módulos de software de seguridad deben estar separados de los módulos de control.
2.4. Otros subsistemas
Fuente de alimentación
Debe ser diseñada para cumplir con las necesidades del sistema de seguridad, la redundancia de las fuentes es una practica comun para mejorar la fiabilidad (uso de UPS, duplicar las baterias (backup de baterias). En todos los casos la conmutación de la fuente debe cumplir con requisitos minimos: Deteccion de fallas previas a afectar el sistema, conmutacion sin afectar al sistema de seguridad, minimizar las fallas de causa comun.
Conexión a tierra
Es preciso una adecuada conexión a tierra para todo sistema E/E/EP, los puntos a considerar son: Protecciones por corrosión, protección catodica, protección contra descargas atmosféricas, protección contra electricidad estática, pruebas de conexión a tierra, fiabilidad de los terminales de conexión a tierra.
Interfaces del operador
Sirven para comunicar información al operador: una accion de parada, diagnostico de sensores, diagnostico de actuadores, estado de la logica, etc.
Para cada mensaje que se quiera mostrar al operador es una buena practica contestar las siguientes preguntas: ¿que eventos son la causa de visualizar este mensaje? ¿El mensaje mostrdo puede y debe ser actualizado? ¿Que acciones causara la desaparición de este mensaje?
De no realizar un análisis claro los mensajes pueden ser una fuente de riego. No se debe sobrecargar al operador de alarmas y mensajes, al punto de que no sean capaces de reaccionar ante una de ellas (Ver publicación 191 de la EMMUA "Asociación de usuarios de materiales y equipos de ingeniería" - 1999)
Cualquier accion del operador debe requerir confirmación.
La informacion al operdor debe incluir:
Las interfaces del oprador tipicas son:
Interfaces de comunicación
Es un conjunto de lineas de hardware que permiten la transferencia de datos entre diferentes componentes de un sistema o entre sistemas.
El diseño de la interfz debe asegurar que ante cualquier falloa en la comunicacion no se afecta al sistema de seguridad.
Sera lo suficientemente robusta contra las interferencias electromagnéticas incluyendo las sobrecargas de tensión.
3. DEFINICIÓN DE CRITERIOS DE ACEPTACIÓN DE SUBSISTEMAS, COMPONENTES Y EQUIPOS EXTERNOS
El proceso de definición de criterios de aceptación para cada subsistema, componente y equipo externo, determina la especificación de los requisitos necesarios para cumplir los requisitos de subsistemas, componentes y equipos externos.
Las actividades secuenciales que definen este proceso son:
3.1. Evidencia de gestión de la calidad.
La primera condición que se debe cumplir para la aceptación de la seguridad es que la calidad del subsistema o equipo haya sido controlada por un sistema eficaz de control de la calidad durante su ciclo de vida completo. Se debe ofrecer evidencia documental.
3.2. Evidencia de gestión de la seguridad
La segunda condición que se debe cumplir para la aceptación de un subsistema es que haya sido gestionada por sistema eficaz de la seguridad y ser consecuente con el proceso de gestión RAMS.
3.3. Evidencia de la seguridad técnica y funcional
Esta condición consiste en evidencias sobre la seguridad del diseño del subsistema como adecuadamente seguro.
3.4. Proceso de aprobación de la seguridad
La evidencia documental debe constar de:
La aprobación de la seguridad podría estar sujeta al cumplimiento de obligaciones adicionales de los organismos de control.
Existen ademas, dependencias entre los sistemas y subsistemas y equipos que condicionan la aceptación de la seguridad, un ejemplo de esta dependencia se muestra en la figura 24:
4. CORREGIR EL PLAN DE SEGURIDAD.
Este proceso examina y actualiza el plan de seguridad y plan de validación para garantizar coherencia entre tareas planificadas antes y después de la distribución.
Partiendo del Plan de seguridad realizado en la fase 2, las actividades que definen este proceso, son: