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

Figura 2. Modelo general: Capas de protección

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

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

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

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 B¹

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.

¹Componentes 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

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

Este artículo analiza el diseño y la implementación de sistemas de control relacionados con la seguridad que se ocupan de todo tipo de sistemas eléctricos, electrónicos y electrónicos programables (incluidos los sistemas basados ​​en computadora). El enfoque general está de acuerdo con la Norma 1508 de la Comisión Electrotécnica Internacional (IEC) propuesta (Seguridad funcional: relacionada con la seguridad 

Todas las funciones a su disposición) (CEI 1993).

Antecedentes

Durante la década de 1980, los sistemas basados ​​en computadora, denominados genéricamente sistemas electrónicos programables (PES), se usaban cada vez más para llevar a cabo funciones de seguridad. Las principales fuerzas impulsoras detrás de esta tendencia fueron (1) la funcionalidad mejorada y los beneficios económicos (particularmente considerando el ciclo de vida total del dispositivo o sistema) y (2) el beneficio particular de ciertos diseños, que solo podían realizarse cuando se usaba tecnología informática. . Durante la introducción temprana de los sistemas basados ​​en computadora se hicieron una serie de hallazgos:

• La introducción del control por computadora fue mal pensada y planificada.
• Se especificaron requisitos de seguridad inadecuados.
• Se desarrollaron procedimientos inadecuados con respecto a la validación del software.
• Se reveló evidencia de mano de obra deficiente con respecto al estándar de instalación de la planta.
• Se generó documentación inadecuada y no se validó adecuadamente con respecto a lo que realmente había en la planta (a diferencia de lo que se pensaba que estaba en la planta).
• Se habían establecido procedimientos de operación y mantenimiento menos que completamente efectivos.
• Evidentemente, existía una preocupación justificada acerca de la competencia de las personas para desempeñar las funciones que se les exigían.

Para resolver estos problemas, varios organismos publicaron o comenzaron a desarrollar pautas para permitir la explotación segura de la tecnología PSA. En el Reino Unido, el Ejecutivo de Salud y Seguridad (HSE) desarrolló pautas para sistemas electrónicos programables utilizados para aplicaciones relacionadas con la seguridad, y en Alemania se publicó un proyecto de norma (DIN 1990). Dentro de la Comunidad Europea, se inició un elemento importante en el trabajo sobre normas europeas armonizadas relacionadas con los sistemas de control relacionados con la seguridad (incluidos los que emplean PES) en relación con los requisitos de la Directiva de máquinas. En los Estados Unidos, la Sociedad de Instrumentos de América (ISA) ha producido un estándar sobre PES para su uso en las industrias de procesos, y el Centro para la Seguridad de Procesos Químicos (CCPS), una dirección del Instituto Americano de Ingenieros Químicos, ha elaborado directrices para el sector de procesos químicos.

Actualmente se está llevando a cabo una importante iniciativa de estándares dentro de IEC para desarrollar un estándar internacional de base genérica para sistemas relacionados con la seguridad eléctricos, electrónicos y electrónicos programables (E/E/PES) que podría ser utilizado por muchos sectores de aplicaciones, incluido el proceso, sector médico, transporte y maquinaria. La norma internacional IEC propuesta consta de siete partes bajo el título general IEC 1508. Seguridad funcional de los sistemas eléctricos/electrónicos/electrónicos programables relacionados con la seguridad. Las distintas partes son las siguientes:

• Parte 1. Requisitos generales
• Parte 2. Requisitos para sistemas eléctricos, electrónicos y electrónicos programables.
• Parte 3. Requisitos de software
• Parte 4. Definiciones
• Parte 5. Ejemplos de métodos para la determinación de los niveles de integridad de la seguridad
• Parte 6. Directrices sobre la aplicación de las Partes 2 y 3
• Parte 7. Resumen de técnicas y medidas.

Cuando esté finalizada, esta norma internacional de base genérica constituirá una publicación de seguridad básica de IEC que cubrirá la seguridad funcional para sistemas eléctricos, electrónicos y electrónicos programables relacionados con la seguridad y tendrá implicaciones para todas las normas de IEC, cubriendo todos los sectores de aplicación con respecto al diseño y uso futuros de sistemas eléctricos/electrónicos/electrónicos programables relacionados con la seguridad. Un objetivo principal de la norma propuesta es facilitar el desarrollo de normas para los diversos sectores (ver figura 1).

Figura 1. Normas genéricas y sectoriales de aplicación

Beneficios y problemas del PSA

La adopción de PES con fines de seguridad tenía muchas ventajas potenciales, pero se reconoció que estas se lograrían solo si se usaban metodologías de diseño y evaluación apropiadas, porque: (1) muchas de las características de los PES no permiten la integridad de la seguridad (que es decir, el rendimiento de seguridad de los sistemas que llevan a cabo las funciones de seguridad requeridas) que debe predecirse con el mismo grado de confianza que tradicionalmente ha estado disponible para sistemas menos complejos basados ​​en hardware ("cableados"); (2) se reconoció que, si bien las pruebas eran necesarias para sistemas complejos, no eran suficientes por sí solas. Esto significaba que incluso si el PES estaba implementando funciones de seguridad relativamente simples, el nivel de complejidad de la electrónica programable era significativamente mayor que el de los sistemas cableados que estaban reemplazando; y (3) este aumento en la complejidad significó que las metodologías de diseño y evaluación tuvieron que ser mucho más consideradas que antes, y que el nivel de competencia personal requerido para lograr niveles adecuados de desempeño de los sistemas relacionados con la seguridad fue posteriormente mayor.

Los beneficios de los PES basados ​​en computadora incluyen lo siguiente:

• la capacidad de realizar verificaciones de prueba de diagnóstico en línea en componentes críticos a una frecuencia significativamente más alta de lo que sería el caso de otro modo
• el potencial para proporcionar enclavamientos de seguridad sofisticados
• la capacidad de proporcionar funciones de diagnóstico y monitoreo de condición que se pueden usar para analizar e informar sobre el rendimiento de la planta y la maquinaria en tiempo real
• la capacidad de comparar las condiciones reales de la planta con las condiciones del modelo "ideal"
• el potencial para proporcionar mejor información a los operadores y, por lo tanto, para mejorar la toma de decisiones que afectan la seguridad
• el uso de estrategias de control avanzadas para permitir que los operadores humanos se ubiquen de forma remota desde entornos peligrosos u hostiles
• la capacidad de diagnosticar el sistema de control desde una ubicación remota.

El uso de sistemas informáticos en aplicaciones relacionadas con la seguridad crea una serie de problemas que deben abordarse adecuadamente, como los siguientes:

• Los modos de falla son complejos y no siempre predecibles.
• La prueba de la computadora es necesaria pero no es suficiente en sí misma para establecer que las funciones de seguridad se realizarán con el grado de certeza requerido para la aplicación.
• Los microprocesadores pueden tener variaciones sutiles entre diferentes lotes y, por lo tanto, diferentes lotes pueden mostrar un comportamiento diferente.
• Los sistemas informáticos desprotegidos son especialmente susceptibles a las interferencias eléctricas (interferencias radiadas, “picos” eléctricos en la red eléctrica, descargas electrostáticas, etc.).
• Es difícil ya menudo imposible cuantificar la probabilidad de falla de los sistemas complejos relacionados con la seguridad que incorporan software. Debido a que ningún método de cuantificación ha sido ampliamente aceptado, la garantía del software se ha basado en procedimientos y estándares que describen los métodos que se utilizarán en el diseño, implementación y mantenimiento del software.

Sistemas de seguridad bajo consideración

Los tipos de sistemas relacionados con la seguridad que se están considerando son los sistemas eléctricos, electrónicos y electrónicos programables (E/E/PES). El sistema incluye todos los elementos, en particular las señales que se extienden desde los sensores o desde otros dispositivos de entrada en el equipo bajo control, y se transmiten a través de autopistas de datos u otras vías de comunicación a los actuadores u otros dispositivos de salida (consulte la figura 2).

Figura 2. Sistema eléctrico, electrónico y electrónico programable (E/E/PES)

El término dispositivo eléctrico, electrónico y electrónico programable se ha utilizado para abarcar una amplia variedad de dispositivos y cubre las siguientes tres clases principales:

1. dispositivos eléctricos tales como relés electromecánicos
2. dispositivos electrónicos tales como instrumentos electrónicos de estado sólido y sistemas lógicos
3. dispositivos electrónicos programables, que incluye una amplia variedad de sistemas informáticos como los siguientes:

• microprocesadores
• microcontroladores
• controladores programables (PC)
• circuitos integrados específicos de la aplicación (ASIC)
• controladores lógicos programables (PLC)
• otros dispositivos informáticos (por ejemplo, sensores, transmisores y actuadores “inteligentes”).

Por definición, un sistema relacionado con la seguridad tiene dos propósitos:

1. Implementa las funciones de seguridad necesarias para lograr un estado seguro para el equipo bajo control o mantiene un estado seguro para el equipo bajo control. El sistema relacionado con la seguridad debe realizar aquellas funciones de seguridad que se especifican en la especificación de requisitos de funciones de seguridad para el sistema. Por ejemplo, la especificación de los requisitos de las funciones de seguridad puede establecer que cuando la temperatura alcanza un cierto valor x, válvula y se abrirá para permitir que el agua entre en el recipiente.
2. Logra, por sí solo o con otros sistemas relacionados con la seguridad, el nivel necesario de integridad de seguridad para la implementación de las funciones de seguridad requeridas. Las funciones de seguridad deben ser realizadas por los sistemas relacionados con la seguridad con el grado de confianza adecuado a la aplicación para lograr el nivel de seguridad requerido para el equipo bajo control.

Este concepto se ilustra en la figura 3.

Figura 3. Características clave de los sistemas relacionados con la seguridad

Fallos del sistema

Para garantizar el funcionamiento seguro de los sistemas relacionados con la seguridad de E/E/PES, es necesario reconocer las diversas causas posibles de falla del sistema relacionado con la seguridad y garantizar que se toman las precauciones adecuadas contra cada una. Las fallas se clasifican en dos categorías, como se ilustra en la figura 4.

Figura 4. Categorías de falla

1. Las fallas de hardware aleatorias son aquellas fallas que resultan de una variedad de mecanismos de degradación normales en el hardware. Hay muchos mecanismos de este tipo que ocurren a diferentes velocidades en diferentes componentes, y dado que las tolerancias de fabricación hacen que los componentes fallen debido a estos mecanismos después de diferentes tiempos de operación, las fallas de un elemento total del equipo que comprende muchos componentes ocurren en momentos impredecibles (aleatorios). Las medidas de confiabilidad del sistema, como el tiempo medio entre fallas (MTBF), son valiosas, pero generalmente solo se refieren a fallas de hardware aleatorias y no incluyen fallas sistemáticas.
2. Las fallas sistemáticas surgen de errores en el diseño, construcción o uso de un sistema que hacen que falle bajo alguna combinación particular de entradas o bajo alguna condición ambiental particular. Si ocurre una falla del sistema cuando surge un conjunto particular de circunstancias, siempre que surjan esas circunstancias en el futuro, siempre habrá una falla del sistema. Cualquier falla de un sistema relacionado con la seguridad que no surja de una falla aleatoria del hardware es, por definición, una falla sistemática. Las fallas sistemáticas, en el contexto de los sistemas relacionados con la seguridad E/E/PES, incluyen:

• fallas sistemáticas debido a errores u omisiones en la especificación de requisitos de las funciones de seguridad
• fallas sistemáticas debido a errores en el diseño, fabricación, instalación u operación del hardware. Estos incluirían fallas que surjan de causas ambientales y errores humanos (por ejemplo, del operador).
• fallas sistemáticas debido a fallas en el software
• fallas sistemáticas debido a errores de mantenimiento y modificación.

Protección de sistemas relacionados con la seguridad

Los términos que se utilizan para indicar las medidas de precaución requeridas por un sistema relacionado con la seguridad para proteger contra fallas aleatorias de hardware y fallas sistemáticas son medidas de integridad de seguridad del hardware y medidas sistemáticas de integridad de la seguridad respectivamente. Las medidas de precaución que un sistema relacionado con la seguridad puede aplicar contra fallas aleatorias de hardware y fallas sistemáticas se denominan integridad de seguridad. Estos conceptos se ilustran en la figura 5.

Figura 5. Términos de desempeño de seguridad

Dentro de la norma internacional propuesta IEC 1508 hay cuatro niveles de integridad de seguridad, denominados Niveles de integridad de seguridad 1, 2, 3 y 4. El Nivel de integridad de seguridad 1 es el nivel de integridad de seguridad más bajo y el Nivel de integridad de seguridad 4 es el más alto. El Nivel de integridad de la seguridad (ya sea 1, 2, 3 o 4) para el sistema relacionado con la seguridad dependerá de la importancia del papel que desempeña el sistema relacionado con la seguridad para lograr el nivel de seguridad requerido para el equipo bajo control. Pueden ser necesarios varios sistemas relacionados con la seguridad, algunos de los cuales pueden estar basados ​​en tecnología neumática o hidráulica.

Diseño de Sistemas Relacionados con la Seguridad

Un análisis reciente de 34 incidentes relacionados con los sistemas de control (HSE) encontró que el 60 % de todos los casos de falla habían sido "incorporados" antes de que se pusiera en uso el sistema de control relacionado con la seguridad (figura 7). Es necesario tener en cuenta todas las fases del ciclo de vida de la seguridad si se van a producir sistemas adecuados relacionados con la seguridad.

Figura 7. Causa principal (por fase) de falla del sistema de control

La seguridad funcional de los sistemas relacionados con la seguridad depende no solo de garantizar que los requisitos técnicos se especifiquen correctamente, sino también de garantizar que los requisitos técnicos se implementen de manera efectiva y que la integridad del diseño inicial se mantenga durante toda la vida útil del equipo. Esto se puede lograr solo si se cuenta con un sistema de gestión de la seguridad eficaz y si las personas involucradas en cualquier actividad son competentes con respecto a las funciones que tienen que realizar. En particular, cuando se trata de sistemas complejos relacionados con la seguridad, es esencial contar con un sistema de gestión de la seguridad adecuado. Esto lleva a una estrategia que asegura lo siguiente:

• Se cuenta con un sistema efectivo de gestión de la seguridad.
• Los requisitos técnicos que se especifican para los sistemas relacionados con la seguridad E/E/PES son suficientes para hacer frente tanto al hardware aleatorio como a las causas de fallas sistemáticas.
• La competencia de las personas involucradas es adecuada para las funciones que deben desempeñar.

Para abordar todos los requisitos técnicos relevantes de la seguridad funcional de manera sistemática, se ha desarrollado el concepto del ciclo de vida de la seguridad. En la figura 1508 se muestra una versión simplificada del ciclo de vida de seguridad en la norma internacional emergente IEC 8. Las fases clave del ciclo de vida de seguridad son:

Figura 8. Papel del ciclo de vida de la seguridad en el logro de la seguridad funcional

• especificación
• diseño e implementación
• instalación y puesta en marcha
• operación y mantenimiento
• cambios después de la puesta en marcha.

Nivel de seguridad

La estrategia de diseño para el logro de niveles adecuados de integridad de la seguridad para los sistemas relacionados con la seguridad se ilustra en la figura 9 y la figura 10. Un nivel de integridad de la seguridad se basa en el papel que desempeña el sistema relacionado con la seguridad en el logro del nivel general. de seguridad para el equipo bajo control. El nivel de integridad de seguridad especifica las precauciones que deben tenerse en cuenta en el diseño contra fallas aleatorias de hardware y sistemáticas.

Figura 9. Rol de los niveles de integridad de la seguridad en el proceso de diseño

Figura 10. Papel del ciclo de vida de la seguridad en el proceso de especificación y diseño

El concepto de seguridad y nivel de seguridad se aplica al equipo bajo control. El concepto de seguridad funcional se aplica a los sistemas relacionados con la seguridad. Debe lograrse la seguridad funcional de los sistemas relacionados con la seguridad si se quiere lograr un nivel adecuado de seguridad para el equipo que genera el peligro. El nivel de seguridad especificado para una situación específica es un factor clave en la especificación de requisitos de integridad de seguridad para los sistemas relacionados con la seguridad.

El nivel de seguridad requerido dependerá de muchos factores, por ejemplo, la gravedad de la lesión, la cantidad de personas expuestas al peligro, la frecuencia con la que las personas están expuestas al peligro y la duración de la exposición. Los factores importantes serán la percepción y las opiniones de las personas expuestas al evento peligroso. Para llegar a lo que constituye un nivel apropiado de seguridad para una aplicación específica, se consideran una serie de entradas, que incluyen lo siguiente:

• requisitos legales relevantes para la aplicación específica
• directrices de la autoridad reguladora de seguridad correspondiente
• discusiones y acuerdos con las diferentes partes involucradas en la aplicación
• estándares de la industria
• normas nacionales e internacionales
• el mejor asesoramiento industrial, experto y científico independiente.

Resumen

Al diseñar y utilizar sistemas relacionados con la seguridad, debe recordarse que es el equipo bajo control el que crea el peligro potencial. Los sistemas relacionados con la seguridad están diseñados para reducir la frecuencia (o probabilidad) del evento peligroso y/o las consecuencias del evento peligroso. Una vez que se ha establecido el nivel de seguridad para el equipo, se puede determinar el nivel de integridad de seguridad para el sistema relacionado con la seguridad, y es el nivel de integridad de seguridad lo que le permite al diseñador especificar las precauciones que deben incorporarse en el diseño para implementarse contra fallas aleatorias de hardware y sistemáticas.

Atrás