SRS, El Eslabón Perdido De La Seguridad Funcional

En el marco del estándar ANSI/ISA-61511:2018 e IEC-61511:2016: “Functional Safety – Safety Instrumented Systems for the Process Industry Sector” existe una cláusula relacionada a la necesidad de que el usuario final establezca como deberían funcionar el SIS y sus Funciones Instrumentadas de Seguridad (SIF) en términos de qué de hacer y qué tan bien deberían funcionar en términos de seguridad, disponibilidad, funcionalidad, operatividad, integridad, confiabilidad y mantenibilidad. Estos requisitos son incluidos en las Especificaciones de los Requerimientos de Seguridad o SRS por sus siglas en inglés (Safety Requirement Specification).

Las SRS recogen toda la información de las fases de “Análisis de Peligros y Riesgo” y “Asignación de las Funciones de Seguridad a las Capas de Protección”, y la convierten en un documento que establece lo que requiere el usuario final, siendo esto el fundamento para el diseño del SIS y para la validación del sistema.

Este documento tiene una influencia determinante en todo el ciclo de vida de seguridad de un SIS, debido a que contiene información detallada necesaria para diseño, construcción, instalación, prueba, operación y mantenimiento de cada SIF, lo que hace del mismo un documento vivo que debe ser actualizado durante toda la vida útil del SIS.

Las SRS siguen vigentes durante la operación y mantenimiento del SIS, ya que es el quien permite tener identificado el desempeño que debemos medir en esta etapa del ciclo de vida. ¿Cuántas veces demando el proceso? ¿Cuántas veces la SIF actuó dentro de sus tiempos de acción y estaba dentro del tiempo de seguridad del proceso? ¿Las tasas de falla se mantienen dentro de lo esperado en el deseño? ¿El tiempo de pruebas periódicas se ha respetado? Toda esa información está en la SRS y permite además hacer un eficiente manejo del cambio cuando es requerido. El contenido de las SRS es responsabilidad del usuario final (no del proveedor, ni del integrador) porque se trata de especificar lo que debe hacer la SIF en función al riesgo.

La normativa establece un mínimo de 29 requisitos generales del SIS y su hardware y 14 requisitos específicos del programa de aplicación, por lo que vale la pena preguntarse desde cuando no hacemos o recibimos una especificación tan detallada, que pueda verificar requisito a requisito contra lo especificado en norma. Recordemos que si una cláusula de la norma no puede ser verificada a plena satisfacción no se debe seguir, en este caso, con el diseño.

Debemos internalizar que cada vez que hacemos que este documento sea débil, restamos valor a todo el proceso de la seguridad funcional, comprometiendo todas las fases restantes del ciclo de vida de seguridad del SIS.

La pregunta que debemos hacernos es ¿de dónde se están tomando todos los datos que no están siendo colocados dentro de la especificación y que son responsabilidad del usuario final y necesarios para diseñar, instalar, probar, operar y mantener el SIS? o peor aún ¿qué pasa si no existe el documento de SRS? Si ese documento no existe no puedo continuar en el Ciclo de vida de seguridad, como lo diseñe, como lo instale, como lo probé, ¿en base a qué?

Nuestra posición como consultores nos permite conocer que hoy día muchos usuarios finales desarrollan en forma consistente las demás actividades del ciclo de vida de seguridad como una tarea normal pero no tienen la cultura de desarrollar o solicitar el desarrollo de las SRS con el nivel de compromiso y conocimiento que se requiere. Muchas veces sucede que el requirente (como el usuario final) no sabe que lo tienen que solicitar y la persona que tienen que vendérselo tampoco en consciente de que lo necesita. Entonces no hay forma de construir seguridad según la norma, si se salta de la fase de asignación a la de diseño y sin tener una directriz clara.

Este trabajo tiene la intención de concientizar sobre la importancia de la adecuada realización de una Especificación de los Requerimientos de Seguridad y su impacto directo sobre la seguridad funcional y la seguridad de procesos