Brazendale, Juan

Brazendale, Juan

Dirección:  Ejecutivo de salud y seguridad, Bootle Merseyside L20 3QZ

País: Reino Unido

Teléfono: 44 151 951 3432

Fax: 44 151 9513418

E-mail: john.brazendale@hse.gov.uk

EDUCACION: licenciatura, 1976; Maestría, 1989

Áreas de interés: Sistemas de control relacionados con la seguridad

 

La maquinaria, las plantas de proceso y otros equipos pueden, si funcionan mal, presentar riesgos de eventos peligrosos como incendios, explosiones, sobredosis de radiación y piezas móviles. Una de las formas en que tales plantas, equipos y maquinaria pueden funcionar mal es por fallas de los dispositivos electromecánicos, electrónicos y electrónicos programables (E/E/PE) utilizados en el diseño de sus sistemas de control o seguridad. Estas fallas pueden surgir de fallas físicas en el dispositivo (p. ej., del desgaste que ocurre aleatoriamente en el tiempo (fallas aleatorias de hardware)); o de fallas sistemáticas (p. ej., errores cometidos en la especificación y el diseño de un sistema que hacen que falle debido a (1) alguna combinación particular de entradas, (2) alguna condición ambiental, (3) entradas incorrectas o incompletas de los sensores, ( 4) ingreso de datos incompletos o erróneos por parte de los operadores, y (5) fallas sistemáticas potenciales debido a un diseño deficiente de la interfaz).

Fallas de los sistemas relacionados con la seguridad

Este artículo cubre la seguridad funcional de los sistemas de control relacionados con la seguridad y considera los requisitos técnicos de hardware y software necesarios para lograr la integridad de seguridad requerida. El enfoque general está de acuerdo con la norma propuesta de la Comisión Electrotécnica Internacional IEC 1508, Partes 2 y 3 (IEC 1993). El objetivo general del proyecto de norma internacional IEC 1508, Seguridad funcional: sistemas relacionados con la seguridad, es garantizar que la planta y el equipo se puedan automatizar de forma segura. Un objetivo clave en el desarrollo de la norma internacional propuesta es prevenir o minimizar la frecuencia de:

    • fallas de los sistemas de control que desencadenan otros eventos que a su vez podrían conducir a un peligro (por ejemplo, falla el sistema de control, se pierde el control, el proceso se descontrola y provoca un incendio, liberación de materiales tóxicos, etc.)
    • fallas en los sistemas de alarma y monitoreo para que los operadores no reciban información en una forma que pueda ser rápidamente identificada y entendida para llevar a cabo las acciones de emergencia necesarias
    • fallas no detectadas en los sistemas de protección, haciéndolos no disponibles cuando se necesitan para una acción de seguridad (por ejemplo, una tarjeta de entrada fallida en un sistema de parada de emergencia).

         

        El artículo “Sistemas relacionados con la seguridad eléctricos, electrónicos y electrónicos programables” establece el enfoque general de gestión de seguridad incorporado en la Parte 1 de IEC 1508 para garantizar la seguridad de los sistemas de control y protección que son importantes para la seguridad. Este artículo describe el diseño de ingeniería conceptual general que se necesita para reducir el riesgo de un accidente a un nivel aceptable, incluida la función de cualquier sistema de control o protección basado en tecnología E/E/PE.

        En la figura 1, el riesgo del equipo, planta de proceso o máquina (generalmente denominado equipo bajo control (EUC) sin dispositivos de protección) está marcado en un extremo de la escala de riesgo de EUC, y el nivel objetivo de riesgo que se necesita para alcanzar el nivel de seguridad requerido está en el otro extremo. En el medio se muestra la combinación de sistemas relacionados con la seguridad e instalaciones externas de reducción de riesgos necesarios para compensar la reducción de riesgos requerida. Estos pueden ser de varios tipos: mecánicos (p. ej., válvulas de alivio de presión), hidráulicos, neumáticos, físicos, así como sistemas E/E/PE. La Figura 2 enfatiza el papel de cada capa de seguridad en la protección del EUC a medida que avanza el accidente.

        Figura 1. Reducción de riesgos: Conceptos generales

        SAF060F1

         

        Figura 2. Modelo general: Capas de protección

        SAF060F2

        Siempre que se haya realizado un análisis de peligros y riesgos en el EUC como se requiere en la Parte 1 de IEC 1508, se ha establecido el diseño conceptual general para la seguridad y, por lo tanto, las funciones requeridas y el nivel de integridad de seguridad (SIL) objetivo para cualquier E/E/ Se ha definido un sistema de control o protección de PE. El objetivo del nivel de integridad de la seguridad se define con respecto a una medida de falla objetivo (consulte la tabla 1).


        Tabla 1. Niveles de integridad de seguridad para sistemas de protección: medidas de falla objetivo

        Nivel de Integridad Seguro                        Modo de operación bajo demanda (Probabilidad de falla en realizar su función de diseño bajo demanda)

        4 10-5 ≤ × 10-4

        3 10-4 ≤ × 10-3

        2 10-3 ≤ × 10-2

        1 10-2 ≤ × 10-1 


        Sistemas de proteccion

        Este documento describe los requisitos técnicos que el diseñador de un sistema relacionado con la seguridad E/E/PE debe tener en cuenta para satisfacer el objetivo de nivel de integridad de seguridad requerido. El enfoque está en un sistema de protección típico que utiliza electrónica programable para permitir una discusión más profunda de los problemas clave con poca pérdida de generalidad. En la figura 3 se muestra un sistema de protección típico, que representa un sistema de seguridad de un solo canal con un apagado secundario activado a través de un dispositivo de diagnóstico. En funcionamiento normal, la condición insegura del EUC (p. ej., exceso de velocidad en una máquina, alta temperatura en una planta química) será detectada por el sensor y transmitida a la electrónica programable, que ordenará a los actuadores (a través de los relés de salida) que pongan el sistema a un estado seguro (p. ej., quitando energía al motor eléctrico de la máquina, abriendo una válvula para aliviar la presión).

        Figura 3. Sistema de protección típico

        SAF060F3

        Pero, ¿y si hay fallas en los componentes del sistema de protección? Esta es la función del apagado secundario, que se activa mediante la función de diagnóstico (autoverificación) de este diseño. Sin embargo, el sistema no es completamente a prueba de fallas, ya que el diseño solo tiene una cierta probabilidad de estar disponible cuando se le solicita que realice su función de seguridad (tiene una cierta probabilidad de falla a pedido o un cierto Nivel de Integridad de Seguridad). Por ejemplo, el diseño anterior podría detectar y tolerar ciertos tipos de fallas en la tarjeta de salida, pero no podría soportar una falla en la tarjeta de entrada. Por lo tanto, su integridad de seguridad será mucho menor que la de un diseño con una tarjeta de entrada de mayor confiabilidad, diagnóstico mejorado o alguna combinación de estos.

        Existen otras causas posibles de fallas en las tarjetas, incluidas fallas físicas “tradicionales” en el hardware, fallas sistemáticas que incluyen errores en la especificación de requisitos, fallas de implementación en el software y protección inadecuada contra las condiciones ambientales (p. ej., humedad). Es posible que los diagnósticos en este diseño de un solo canal no cubran todos estos tipos de fallas y, por lo tanto, esto limitará el nivel de integridad de seguridad logrado en la práctica. (La cobertura es una medida del porcentaje de fallas que un diseño puede detectar y manejar de manera segura).

        Requerimientos Técnicos

        Las partes 2 y 3 del borrador de IEC 1508 proporcionan un marco para identificar las diversas causas potenciales de falla en el hardware y el software y para seleccionar características de diseño que superen esas posibles causas de falla apropiadas para el nivel de integridad de seguridad requerido del sistema relacionado con la seguridad. Por ejemplo, el enfoque técnico general para el sistema de protección en la figura 3 se muestra en la figura 4. La figura indica las dos estrategias básicas para superar fallas y fallas: (1) prevención de fallas, donde se tiene cuidado para evitar que se creen fallas; y 2) Tolerancia a fallos, donde el diseño se crea específicamente para tolerar fallas específicas. El sistema de un solo canal mencionado anteriormente es un ejemplo de un diseño tolerante a fallas (limitado) donde se utilizan diagnósticos para detectar ciertas fallas y poner el sistema en un estado seguro antes de que ocurra una falla peligrosa.

        Figura 4. Especificación de diseño: solución de diseño

        SAF060F4

        Prevención de fallas

        La prevención de fallas intenta evitar que se introduzcan fallas en un sistema. El enfoque principal es utilizar un método sistemático de gestión del proyecto para que la seguridad se trate como una cualidad definible y manejable de un sistema, durante el diseño y, posteriormente, durante la operación y el mantenimiento. El enfoque, que es similar a la garantía de calidad, se basa en el concepto de retroalimentación e implica: (1) planificar (definir los objetivos de seguridad, identificar las formas y los medios para lograr los objetivos); (2) medición logro contra el plan durante la implementación y (3) aplicando realimentación para corregir cualquier desviación. Las revisiones de diseño son un buen ejemplo de una técnica para evitar fallas. En IEC 1508, este enfoque de "calidad" para evitar fallas se ve facilitado por los requisitos para usar un ciclo de vida de seguridad y emplear procedimientos de gestión de seguridad tanto para hardware como para software. Para estos últimos, estos a menudo se manifiestan como procedimientos de aseguramiento de la calidad del software como los descritos en la norma ISO 9000-3 (1990).

        Además, las Partes 2 y 3 de IEC 1508 (sobre hardware y software, respectivamente) califican ciertas técnicas o medidas que se consideran útiles para evitar fallas durante las diversas fases del ciclo de vida de seguridad. La Tabla 2 da un ejemplo de la Parte 3 para la fase de diseño y desarrollo del software. El diseñador usaría la tabla para ayudar en la selección de técnicas para evitar fallas, según el nivel de integridad de seguridad requerido. Con cada técnica o medida en las tablas, hay una recomendación para cada nivel de integridad de seguridad, del 1 al 4. El rango de recomendaciones cubre Altamente recomendado (HR), Recomendado (R), Neutral, ni a favor ni en contra (—) y No recomendado (NR).

        Tabla 2. Diseño y desarrollo de software

        Técnica/medida

        SIL 1

        SIL 2

        SIL 3

        SIL 4

        1. Métodos formales que incluyen, por ejemplo, CCS, CSP, HOL, LOTOS

        -

        R

        R

        HR

        2. Métodos semiformales

        HR

        HR

        HR

        HR

        3. Estructurado. Metodología que incluye, por ejemplo, JSD, MASCOT, SADT, SSADM y YOURDON

        HR

        HR

        HR

        HR

        4. Enfoque modular

        HR

        HR

        HR

        HR

        5. Estándares de diseño y codificación

        R

        HR

        HR

        HR

        HR = muy recomendable; R = recomendado; NR = no recomendado;— = neutral: la técnica/medida no está ni a favor ni en contra del SIL.
        Nota: se seleccionará una técnica/medida numerada de acuerdo con el nivel de integridad de la seguridad.

        Tolerancia a fallos

        IEC 1508 requiere niveles crecientes de tolerancia a fallas a medida que aumenta el objetivo de integridad de seguridad. El estándar reconoce, sin embargo, que la tolerancia a fallas es más importante cuando los sistemas (y los componentes que componen esos sistemas) son complejos (designados como Tipo B en IEC 1508). Para sistemas menos complejos, “bien probados”, el grado de tolerancia a fallas puede relajarse.

        Tolerancia contra fallas de hardware aleatorias

        La Tabla 3 muestra los requisitos para la tolerancia a fallas contra fallas de hardware aleatorias en componentes de hardware complejos (por ejemplo, microprocesadores) cuando se usa en un sistema de protección como el que se muestra en la figura 3. El diseñador puede necesitar considerar una combinación apropiada de diagnóstico, tolerancia a fallas y verificaciones de prueba manuales para superar esta clase de falla, dependiendo del Nivel de Integridad de Seguridad requerido.


        Tabla 3. Nivel de integridad de seguridad: requisitos de falla para componentes de tipo B1

        1 Las fallas no detectadas relacionadas con la seguridad se detectarán mediante la verificación de prueba.

        2 Para los componentes sin cobertura de diagnóstico medio en línea, el sistema deberá poder realizar la función de seguridad en presencia de una sola falla. Los fallos no detectados relacionados con la seguridad se detectarán mediante la verificación de pruebas.

        3 Para componentes con alta cobertura de diagnóstico en línea, el sistema debe poder realizar la función de seguridad en presencia de una sola falla. Para componentes sin alta cobertura de diagnóstico en línea, el sistema deberá poder realizar la función de seguridad en presencia de dos fallas. Los fallos no detectados relacionados con la seguridad se detectarán mediante la verificación de pruebas.

        4 Los componentes deberán poder realizar la función de seguridad en presencia de dos fallas. Las fallas se detectarán con alta cobertura de diagnóstico en línea. Los fallos no detectados relacionados con la seguridad se detectarán mediante la verificación de pruebas. El análisis cuantitativo del hardware se basará en suposiciones del peor de los casos.

        1Componentes cuyos modos de falla no están bien definidos o no se pueden probar, o para los cuales existen datos deficientes sobre fallas de la experiencia de campo (por ejemplo, componentes electrónicos programables).


        IEC 1508 ayuda al diseñador al proporcionar tablas de especificaciones de diseño (consulte la tabla 4) con parámetros de diseño indexados contra el nivel de integridad de seguridad para una serie de arquitecturas de sistemas de protección de uso común.

        Tabla 4. Requisitos para el Nivel de Integridad de Seguridad 2 - Arquitecturas de sistemas electrónicos programables para sistemas de protección

        Configuración del sistema PE

        Cobertura de diagnóstico por canal

        Intervalo de prueba de prueba fuera de línea (TI)

        Tiempo medio para viaje espurio

        PE simple, E/S simple, ext. WD

        Alta

        6 meses

        1.6 años

        Doble PE, E/S única

        Alta

        6 meses

        10 años

        PE doble, E/S doble, 2oo2

        Alta

        3 meses

        1,281 años

        PE doble, E/S doble, 1oo2

        Ninguna

        2 meses

        1.4 años

        PE doble, E/S doble, 1oo2

        Baja

        5 meses

        1.0 años

        PE doble, E/S doble, 1oo2

        Medio

        18 meses

        0.8 años

        PE doble, E/S doble, 1oo2

        Alta

        36 meses

        0.8 años

        PE doble, E/S doble, 1oo2D

        Ninguna

        2 meses

        1.9 años

        PE doble, E/S doble, 1oo2D

        Baja

        4 meses

        4.7 años

        PE doble, E/S doble, 1oo2D

        Medio

        18 meses

        18 años

        PE doble, E/S doble, 1oo2D

        Alta

        48 + meses

        168 años

        PE triple, E/S triple, IPC, 2oo3

        Ninguna

        1 meses

        20 años

        PE triple, E/S triple, IPC, 2oo3

        Baja

        3 meses

        25 años

        PE triple, E/S triple, IPC, 2oo3

        Medio

        12 meses

        30 años

        PE triple, E/S triple, IPC, 2oo3

        Alta

        48 + meses

        168 años

         

        La primera columna de la tabla representa arquitecturas con diversos grados de tolerancia a fallas. En general, las arquitecturas ubicadas cerca de la parte inferior de la tabla tienen un mayor grado de tolerancia a fallas que las que se encuentran cerca de la parte superior. Un sistema 1oo2 (uno de dos) es capaz de soportar cualquier falla, al igual que 2oo3.

        La segunda columna describe el porcentaje de cobertura de cualquier diagnóstico interno. Cuanto más alto sea el nivel de los diagnósticos, más fallas se detectarán. En un sistema de protección, esto es importante porque, siempre que el componente defectuoso (por ejemplo, una tarjeta de entrada) se repare en un tiempo razonable (a menudo 8 horas), hay poca pérdida en la seguridad funcional. (Nota: este no sería el caso de un sistema de control continuo, ya que es probable que cualquier falla provoque una condición insegura inmediata y la posibilidad de un incidente).

        La tercera columna muestra el intervalo entre pruebas de calidad. Son pruebas especiales que se requieren realizar para ejercitar a fondo el sistema de protección para asegurar que no haya fallas latentes. Por lo general, estos son realizados por el proveedor del equipo durante los períodos de parada de la planta.

        La cuarta columna muestra la tasa de disparos espurios. Un disparo espurio es aquel que hace que la planta o el equipo se apaguen cuando no hay desviación del proceso. El precio de la seguridad suele ser una mayor tasa de disparos falsos. Un sistema de protección redundante simple, 1oo2, tiene, con todos los demás factores de diseño sin cambios, un nivel de integridad de seguridad más alto pero también una tasa de disparo espurio más alta que un sistema de un solo canal (1oo1).

        Si no se utiliza una de las arquitecturas de la tabla o si el diseñador desea realizar un análisis más fundamental, la norma IEC 1508 permite esta alternativa. Las técnicas de ingeniería de confiabilidad, como el modelado de Markov, se pueden usar para calcular el elemento de hardware del nivel de integridad de seguridad (Johnson 1989; Goble 1992).

        Tolerancia frente a fallos sistemáticos y de causa común

        Esta clase de falla es muy importante en los sistemas de seguridad y es el factor limitante en el logro de la integridad de la seguridad. En un sistema redundante, se duplica un componente o subsistema, o incluso todo el sistema, para lograr una alta confiabilidad a partir de partes de menor confiabilidad. La mejora de la confiabilidad ocurre porque, estadísticamente, la posibilidad de que dos sistemas fallen simultáneamente por fallas aleatorias será el producto de las confiabilidades de los sistemas individuales y, por lo tanto, será mucho menor. Por otro lado, las fallas sistemáticas y de causa común hacen que los sistemas redundantes fallen coincidentemente cuando, por ejemplo, un error de especificación en el software hace que las partes duplicadas fallen al mismo tiempo. Otro ejemplo sería la falla de una fuente de alimentación común a un sistema redundante.

        IEC 1508 proporciona tablas de técnicas de ingeniería clasificadas según el nivel de integridad de seguridad que se considera eficaz para brindar protección contra fallas sistemáticas y de causa común.

        Ejemplos de técnicas que brindan defensas contra fallas sistemáticas son la diversidad y la redundancia analítica. La base de la diversidad es que si un diseñador implementa un segundo canal en un sistema redundante utilizando una tecnología o un lenguaje de software diferentes, las fallas en los canales redundantes pueden considerarse independientes (es decir, una baja probabilidad de falla coincidente). Sin embargo, particularmente en el área de los sistemas basados ​​en software, se sugiere que esta técnica puede no ser efectiva, ya que la mayoría de los errores están en la especificación. La redundancia analítica intenta explotar información redundante en la planta o máquina para identificar fallas. Para las otras causas de fallas sistemáticas, por ejemplo, tensiones externas, el estándar proporciona tablas que brindan consejos sobre buenas prácticas de ingeniería (por ejemplo, separación de cables de señal y de alimentación) indexadas contra el nivel de integridad de seguridad.

        Conclusiones

        Los sistemas basados ​​en computadora ofrecen muchas ventajas, no solo económicas, sino también el potencial para mejorar la seguridad. Sin embargo, la atención al detalle requerida para realizar este potencial es significativamente mayor que en el caso de usar componentes de sistemas convencionales. En este artículo se han esbozado los principales requisitos técnicos que un diseñador debe tener en cuenta para explotar con éxito esta tecnología.

         

        Atrás

        " EXENCIÓN DE RESPONSABILIDAD: La OIT no se responsabiliza por el contenido presentado en este portal web que se presente en un idioma que no sea el inglés, que es el idioma utilizado para la producción inicial y la revisión por pares del contenido original. Ciertas estadísticas no se han actualizado desde la producción de la 4ª edición de la Enciclopedia (1998)."

        Contenido