Desde que existen los sistemas programables en aplicaciones de seguridad y de control, tenemos la tentación de pensar que cualquier problema es solucionable con programación y que el software da para todo y en cualquier instancia de la vida útil del sistema. Alguna vez escuche la frase asociada a que el software es el mundo del pensamiento posterior y la misma estaba atada a esa creencia de que podemos resolverlo todo en el momento que se presente el problema, no previendo el problema. Eso en seguridad funcional se puede pagar muy caro.
Cuando se crea o codifica una aplicación, existe un número casi infinito de soluciones programables que satisfacen los mismos requisitos funcionales. Sin embargo, no todas estas soluciones o programas comparten los mismos niveles de calidad. Es decir, no todos son igualmente eficientes en el consumo de recursos (por ejemplo: memoria del procesador), legibles, fáciles de probar y fáciles de mantener.
En seguridad funcional, no basta con crear el Programa de Aplicación que funcione correctamente sino además, este debe ser robusto, eficiente, documentado, fácil de mantener, de actualizar y de probar. En general, muchas personas están capacitadas para codificar aplicaciones pero un número bastante reducido de ellas están capacitadas para hacerlo conforme a los parámetros de calidad (integridad) que se requiere, según la norma IEC 61511, para el Programa de Aplicación de los Sistemas Instrumentados de Seguridad.
Esta norma define los requisitos para la elaboración de la solución lógica específica para la aplicación del usuario que contiene, en general, las secuencias lógicas, permisivos, límites y expresiones que controlan las entradas, las salidas, los cálculos y las decisiones para cumplir los requisitos funcionales del SIS (IEC 61511: 2016 – Clausula 3.2.76.1); además, establece un ciclo de vida para su gestión como el que se muestra a continuación.
Ciclo de Vida de Seguridad del programa de aplicación.
La norma IEC 61511 contempla en su apartado 12, que se realice un Programa de Aplicación que pueda ser gestionado, lo que implica que esté bien documentado, sea trazable, que permita su modificación de manera sencilla, sea modular, tome en cuenta las restricciones del hardware, se utilicen adecuadamente las librerías incluidas, entre algunos otros aspectos que se deben considerar. Además, se debe garantizar en todo momento que el diseño y la implementación de las Funciones Instrumentadas de Seguridad (SIF) logren la Seguridad Funcional requerida.
Cuando decimos que el Programa de Aplicación debe estar bien documentado, debemos asegurarnos de indicar claramente las SIF soportadas y su Nivel de Integridad de Seguridad (SIL), tiempo de activación, tiempo de retardo, descripción de la función, sintaxis de los tag utilizados, rangos de operación, escenarios y modos de operación, comentar rutinas o pasos claves del programa, no dejar nada a la imaginación o asumir que cualquier programador lo entenderá.
No debemos perder de vista aspectos importantes de rendimiento y eficiencia del programa de aplicación, revisar y probar orden de ejecución, permisivos, memoria utilizada, modos de funcionamiento, límites en datos y parámetros, bugs, bypass, identificar los estados peligrosos que puede generar el programa de aplicación y diseñar su solución.
Como último punto y no menos importante, se deben crear las facilidades dentro de la estructura del Programa de Aplicación para las rutinas de las facilidades de mantenimiento, autodiagnósticos de dispositivos externos, ensayos periódicos, pruebas de diagnósticos, auto-monitoreo del propio programa.
En resumen, y como buenas prácticas, se debe programar teniendo en cuenta:
- Gastar los recursos como propios. Lograr el mejor uso posible de los recursos.
- Codificar para niños (a prueba de tontos). Escribir los programas lo más simple y directo posible, buscando optimizar el rendimiento de la aplicación.
- Documentar pensando en el otro. Todo programa debe ser previamente comentado, explicando brevemente el propósito, funcionamiento y el resultado esperado.
- Estructurar para que te lea hasta tu abuela. Dentro de las funciones definidas, establecer un espaciado, que resalte la estructura funcional de la aplicación y facilite la lectura al programador al que le corresponda analizar el código.
- Usar las ventajas disponibles. Gestionar los errores de hardware y la pérdida de datos, incluir autodiagnósticos de los sistemas con quien interactúa como los sensores de campo y elemento final.
- Ordenar la casa. Definir el orden de los programas, rutinas, secuencia de tareas, quien va primero y quien después.
- Guardar tus secretos y mantener tu seguridad. Tomar en cuenta y definir claramente los niveles de acceso y protección del software.
- Armar una buena caja de herramientas. Seleccionar y aplicar los métodos, técnicas y herramientas necesarias, según la fase del ciclo de vida.
- Tipificar soluciones confiables. Definir bloques típicos y manual de aplicación para soluciones particulares, utilizando las librerías disponibles señaladas en el manual de seguridad.
- Controlar las Versiones. Llevar una bitácora de las cambios y mejoras realizadas en cada versión del programa de aplicación y definir un lugar específico donde esté resguardada la más actual.
- Probar, probar y probar.
“La imaginación exagera, la razón subestima, el sentido común modera.”
Marlene Dietrich (1901-1992) Actriz y cantante alemana.
Luis Durán
FSEng TÜV SÜD TP18051526
Romel Rodríguez
Functional Safety Expert TÜV SÜD TP18010990 | ISA84/IEC 61511 Expert | FSEng TÜV Rheinland 575/07 | PHA Leader