Malentendidos principales acerca de la seguridad funcional

A menudo, los manufactures simplemente calculan un valor PFD/PFH para su sistema o subsistema y luego reclaman un SIL por ello. PFH/PFD expresa la probabilidad de una falla peligrosa de un sistema (o subsistema) relacionada con la seguridad por hora (PFH) o bajo demanda (PFD). Ambos valores abordan fallas de hardware aleatorias y generalmente se calculan con el uso de FMEDA. Cumplir con un nivel de integridad de seguridad (SIL) específico requiere no solo el control de fallas aleatorias de hardware, sino también evitar y controlar fallas sistemáticas en hardware y software. Este último se expresa como capacidad sistemática (SC, valores de 1 a 4, correspondientes a los cuatro valores SIL) y refleja los métodos y técnicas utilizados durante el desarrollo del sistema relacionado con la seguridad. Por lo tanto, un SIL siempre consta de ambos: PFD/PFH y una determinación de la solidez de su proceso de desarrollo, es decir, el SC.

En ocasiones, los integradores de sistemas y los manufactures de plantas requieren que sus proveedores entreguen sistemas de control para el funcionamiento normal con un SIL, pensando que esto asegurará una cierta confiabilidad del sistema de control y / o utilidad. Pero el objetivo de una función de seguridad (que se realiza mediante un sistema relacionado con la seguridad) es poner un equipo bajo control (EUC) en un estado seguro para no aumentar la disponibilidad.

Un estado seguro de EUC es el resultado del análisis de peligros y riesgos y depende de los diferentes modos operativos. En este contexto, con frecuencia observamos malentendidos sobre estrategias y conceptos relacionados con escenarios a prueba de fallas, por ejemplo, apagar el EUC en caso de falla, y escenarios operativos de falla, es decir, p. Ej. mantenga el EUC en funcionamiento tanto como sea posible.

Las fallas de hardware aleatorias (y la confiabilidad) se calculan en función de las tasas de falla. En términos de seguridad funcional, las tasas de fallas se dividen en fallas seguras y peligrosas. En el cálculo de los valores de PFD/PFH solo se consideran las fallas peligrosas (que impiden que la función de seguridad funcione según lo previsto). Por lo tanto, un SIL es solo un grado de confiabilidad de que la función de seguridad realizará según lo previsto cuando sea necesario para poner el EUC en un estado seguro.

Los perros guardianes del microcontrolador (µC) a menudo simplemente restablecen el controlador pero no controlan ninguna salida de una manera directa e independiente. En caso de una falla dentro del (µC), se requiere un comportamiento determinista de la salida. No es suficiente utilizar un perro guardián interno, porque no se garantiza que la salida vaya al estado deseado: el perro guardián interno es parte del microcontrolador defectuoso, por lo que no se puede garantizar que funcione correctamente.

Seguimos observando enfoques para reclamar la capacidad sistemática para el software existente en función de la experiencia operativa (Ruta 2S en IEC 61508). Dado que IEC TS 61508-3-1, todos los fallos individuales del SW deben detectarse y notificarse durante el periodo de observación y también deben documentarse todas las combinaciones de datos de entrada, secuencias de ejecución y relaciones de tiempo. Este enfoque generalmente no es posible desde un punto de vista práctico.

Por lo general, observamos diseños de sistemas en los que las piezas/componentes/elementos de diseño que no son de seguridad se mezclan con elementos de seguridad. Este es un enfoque estándar para reducir la complejidad y los costos de sistema. Sin embargo, se requiere evidencia de la ausencia de interferencia cuando se utilizan técnicas de diseño de niveles de integridad de seguridad mezclados. El análisis se realizará a nivel detallado de hardware o software (según el sistema), teniendo en cuenta los posibles modos de falla de las partes que no son de seguridad y el impacto relacionado en la seguridad (es decir, sobretensión, datos incorrectos, cortocircuito en partes que no son de seguridad, etc.).

En el desarrollo de software crítico para la seguridad, el uso de herramientas automatizadas es hoy en día el estado del arte en términos de eficiencia y seguridad. Sin embargo, hemos visto varias veces el uso incorrecto de dichas herramientas. La especificación de la prueba unitaria se redactará primer lugar basándose en la especificación de la unidad/módulo de software y no solo mediante el análisis de caja blanco del código fuente. El objetivo es para probar el comportamiento funcional deseado de la unidad de software. También se proporcionará la conformidad de la evidencia de la cobertura de prueba requerida a nivel de código, para la cual se puede requerir un análisis de caja blanca, pero no es el único objetivo de la prueba unitaria.

En los sistemas modernos y complejos relacionados con la seguridad, el uso de sensores inteligentes está adquiriendo cada vez más importancia. Las funciones de los sensores se proporcionarán con la integridad requerida o se justificará la libertad de interferencia a la función de seguridad general. Algunos diseños de sistemas se basan erróneamente en la suposición de que los modos de falla de los sensores inteligentes complejos (es decir, con unidad de procesamiento lógico, protocolo de comunicación, etc.) pueden ser diagnosticados y mitigados por alguna unidad de seguridad externa dentro de la cobertura de diagnóstico requerida y la detección de fallas/tiempo de reacción.

Vemos problemas recurrentes relacionados con la falta de protección/supervisión de la fuente de alimentación. Las normas de seguridad no especifican en detalle cómo se implementarán las medidas de sobretensión/subtensión, pero se deben implementar mecanismos de protección adecuados en función del nivel de SIL requerido. El uso de un mecanismo de protección de sobretensión no redundante para la arquitectura que requiere HFT>1 es, por ejemplo, un problema recurrente típico. La monitorización de la tensión de alimentación (incluida la reacción requerida, como el apagado y el estado seguro) debe realizarse mediante un componente independiente que sea capaz de un rango de tensión más amplio, y, por lo tanto, no se haya visto afectado por la condición de sobretensión o subtensión. Incluso una pequeña sobretensión podría haber dañado permanentemente parte del microcontrolador, sin ser obvio. Por tanto, un reinicio del microcontrolador después de una sobretensión no es una medida adecuada; después de una condición de subtensión, un reinicio puede ser correcto, siempre que la subtensión no persista.

La detección de sobretemperatura y la reacción respectiva (entrar en estado seguro, apagado, …) no pueden ser realizadas por un componente (por ejemplo, microcontrolador) que se opera correctamente fuera de los rangos especificados en caso de condición de sobrecalentamiento. Un simple reinicio tampoco es útil aquí, se debe asumir que la condición de sobrecalentamiento persistente o ya está presente durante el encendido. A veces, las normas de seguridad no consideran la temperatura baja (es decir, EN 50129), pero las condiciones de aplicación (manual del usuario) deben garantizar que el dispositivo solo funcione dentro de los rangos de temperatura especificados (para todos los componentes).

La abreviatura SIL (nivel de integridad de seguridad) se utiliza en varios estándares. En cada estándar, sin embargo, se relaciona con diferentes requisitos de proceso, arquitectónicos y técnicos. Algunos de los estándares utilizan diferentes abreviaturas como ASIL (SIL automotriz). Algunos otros utilizan la misma abreviatura (SIL), con el riesgo de confusión y malentendidos.

Por ejemplo, el nivel SAS (en alemán: “Sicherheitsanforderungsstufe” para el nivel de integridad de seguridad), tal como lo usa SIRF (Sicherheitsrichtlinie Fahrzeug; EBA), no es el mismo que el nivel SIL (“nivel de integridad de seguridad”) tal como lo usa EN 50128 / EN 50129. SIRF (SAS) solo utiliza parte de las medidas enumeradas en el apéndice E de EN 50129, menos medidas organizativas y de proceso, y ningún límite definido para la tasa de riesgo. SIL en el contexto de IEC 61508 es diferente de SIL en el contexto de EN 50129. En algún momento, se agrega más complejidad al definir SIL como nivel de integridad del software en lugar de nivel de integridad de la seguridad (consulte, por ejemplo, EN 50657).

No es posible elevar el nivel SIL de un sistema que combina sistemas que no tienen evidencia de seguridad o que usan redundancia homogénea. Por ejemplo, no es posible aumentar SIL a SIL4 simplemente combinando varias sistemas/canales SIL2 (por ejemplo, alcanzar SIL3 en el nivel del sistema mediante varios sistemas de control SIL2). Una razón es que, por ejemplo, los procesos de software SIL2 no previenen las fallas de software sistemáticas de la misma manera (integridad) que se requiere para las de SIL4. El estándar IEC 61508 permite aumentar la capacidad sistemática en 1 si se utilizan dos sistemas independientes en una estructura de doble canal. En caso de redundancia homogénea, esto no es posible. Otras normas (es decir, EN 50129) no ofrecen esta posibilidad.

La causa común a menudo se olvida en el análisis de árbol de fallas (FTA). Las fallas que pueden afectar a varias partes de un sistema al mismo tiempo (por ejemplo, pérdida de suministro de energía) deben incluirse como eventos básicos en todas las ramas relevantes del árbol de fallas. Alternativa: implemente la causa común mediante el uso de un “factor beta” en la herramienta FTA.

La definición de SIL (nivel de integridad de seguridad) se aplica a funciones que se han derivado en origen por algún tipo de análisis/clasificación de riesgos. Para un sistema/componente es común escuchar frases como “un controlador SIL 2”, “un sistema de frenos SIL3”, etc. Hablando correctamente, el termina SIL solo se relaciona con funciones específicas (de seguridad). Qué funciones son de seguridad es el objetivo del análisis de riesgos. Una definición más correcta es que un “sistema es capaz de implementar funciones de seguridad hasta SILx”. Esto significa que el sistema cumple con los requisitos de proceso, arquitectónicos y técnicos de las normas.

Los límites del sistema que se analizarán desde el punto de vista de la seguridad, y las interfaces con otras partes del sistema, a menudo no están claramente definidas al comienzo de un proyecto. Por ejemplo, no está claro qué componentes son parte del sistema, qué variantes de sensores/actuadores se considerarán, etc. Comenzar un análisis de seguridad sin definir el alcance simplemente no es posible, sin evitar varias iteraciones cada vez que se cambia el alcance.

No existe algo como un nivel SIL separado de un bloque de detección y monitoreo de fallas (diagnóstico) que pertenezca a una función de seguridad clasificada para ciertos SIL. Algunas normas permiten reducir el nivel de integridad requerido en 1, pero desde el punto de vista de la seguridad funcional, el diagnóstico es parte de las funciones de seguridad. Los requisitos de integridad también se aplican al diagnóstico. Un análisis adicional de la descomposición puede permitir reducir el nivel de integridad, pero generalmente no excluye ningún requisito de seguridad.

Algunas medidas de integridad/diagnóstico se realizan en cada inicio del sistema (por ejemplo, prueba de RAM, verificación de Flash CRC, pruebas de salida, etc.). Estas pruebas son muy importantes, ya que se utiliza para argumentar sobre medidas de diagnóstico o para el tiempo de detección de fallas (intervalo de prueba) en el análisis de seguridad. Sin embargo, en algún momento la condición de operación puede cambiar (nuevo proyecto, nuevos requisitos, etc.). Los sistemas que se apagan con regularidad permanecen encendidos durante más tiempo. Por ejemplo, los sistemas ferroviarios modernos hoy en día a menudo se encienden continuamente, sin reiniciarse cada mañana. En tales casos, las medidas de diagnóstico previstas no serán efectivas. Si es necesario para el análisis de seguridad, el reinicio regular debe especificarse explícitamente en el manual de seguridad, la documentación del operador, etc.