EL reto de la convivencia: Programa Estándar vs. Programa de Seguridad
Para un programador junior, uno de los momentos de mayor tensión en TIA Portal es cuando, tras una pequeña modificación en el programa estándar, el sistema solicita compilar y cargar el programa de seguridad. Esto no solo lleva tiempo, sino que cambia la firma (checksum) y la fecha de modificación, algo que en entornos regulados puede exigir una nueva validación documental.
¿Cómo podemos evitar esto? La clave está en el concepto de "Ausencia de retroactividad" (Interference-free).
El Marco Normativo: IEC 61508
La norma IEC 61508 (Seguridad funcional de los sistemas eléctricos/electrónicos/electrónicos programables relacionados con la seguridad) es el pilar sobre el que se asienta la seguridad industrial.
Específicamente, para el desarrollo de software, debemos fijarnos en la Parte 3 de la norma. El concepto al que me refiero se conoce formalmente como "Independencia de los elementos / Libertad de interferencias" (Freedom from interference).
- Apartado Específico: IEC 61508-3, sección 7.4.2.8 y el Anexo F.
- ¿Qué dice el párrafo? Establece que si un sistema ejecuta funciones de seguridad y funciones no relacionadas con la seguridad, todas las funciones deben tratarse como de seguridad, a menos que se pueda demostrar independencia entre ellas. Es decir, el software estándar no debe poder influir en el comportamiento del software de seguridad, ni por escritura de memoria, ni por bloqueo de ciclos de CPU.
Enlace Oficial (SIOS): Puedes encontrar el manual detallado de "SIMATIC Safety - Configuración y programación" (ID: 54110126) en el portal de soporte de Siemens: Manual de Programación de Seguridad S7-1200/1500. Consulta el capítulo 8 sobre "Intercambio de datos entre el programa estándar y el programa de seguridad".
Desacoplamiento del programa de seguridad del programa de usuario estándar
Para intercambiar datos entre el programa de usuario estándar y el programa de seguridad, recomendamos definir bloques de datos específicos (bloques de datos de transferencia) en los que se guardarán los datos que deben intercambiarse. Esto permite desacoplar los bloques del programa de usuario estándar de los del programa de seguridad. Mientras no se modifiquen estos bloques de datos, las modificaciones del programa de usuario estándar no afectarán al programa de seguridad (ni a la inversa).
La Estrategia de los "DBs Intermedios" (Interface DBs)
Para mantener la independencia de ambos mundos, la mejor práctica profesional es crear una "aduana" de datos mediante Data Blocks (DBs) Globales Estándar.
1. Del Programa Estándar → Al Programa de Seguridad
Para enviar señales (como condiciones de proceso o modos de operación) al programa de seguridad:
- Método: Crea un DB Global Estándar (p.ej. DB_Std_to_Safety).
- Flujo: El programa normal escribe sus estados aquí. El programa de seguridad lee estas variables.
- Ventaja: Al centralizar todas las señales externas que necesita la seguridad en un solo DB de interfaz, protegemos el programa de seguridad frente a cambios en el resto del proyecto.
- Si realizas modificaciones, añades variables o cambias lógicas en otros tantos DBs o FBs de tu programa normal, el Checksum de seguridad permanecerá intacto. Solo si tocas el DB de interfaz específico, TIA Portal te pedirá actualizar la seguridad. Esto reduce drásticamente los tiempos de carga y los riesgos de des-validación durante la puesta en marcha.
2. Del Programa de Seguridad → Al Programa Estándar
Para monitorizar estados de seguridad (p.ej. "E-Stop OK" o "Puerta Cerrada") en el SCADA o lógica normal:
- Método: Utiliza un DB Global de Seguridad (p.ej. DB_Safety_to_Std).
- Flujo: El programa de seguridad escribe los resultados de su lógica en este DB de Seguridad. El programa normal lee de allí.
- ¿Por qué no leer directamente del DB de Seguridad? Aunque TIA Portal permite que el programa estándar lea variables de un F-DB, escribir los estados en un DB intermedio blinda la arquitectura y facilita la organización del mapa de memoria para comunicaciones externas.
Beneficios de esta Arquitectura
- Protección de la Firma: Puedes modificar el 90% de tu código estándar sin que la firma de seguridad cambie.
- Mantenibilidad: Cualquier técnico que herede el proyecto sabrá exactamente dónde buscar los puntos de unión entre ambos programas.
- Depuración: Es mucho más sencillo forzar señales en un DB intermedio durante la puesta en marcha para probar condiciones de seguridad.
Tabla de Buenas Prácticas: Comunicación Estándar vs. Safety
| Concepto | Práctica Recomendada (OneDoor)Error | Común / Práctica de Riesgo |
| P.Estandar hacia P.Safety | El programa estándar escribe en un DB Global Estándar de Interfaz. El programa de seguridad lee de ahí. | Intentar forzar señales o usar punteros complejos desde el programa estándar hacia el bloque F. |
| P.Safety hacia P.Estandar | El programa de seguridad escribe sus estados en un DB Global de Seguridad. El programa normal consulta ese DB. | Leer directamente las variables del F-DB en la lógica estándar o HMI (dificulta la portabilidad y el mapeo). |
| Protección del Checksum | Realizar cambios en el programa normal, FBs de proceso o DBs de datos fuera de la interfaz. | Vincular la lógica de seguridad a DBs de producción que cambian constantemente. |
| Compilación y Carga | Solo se requiere carga de seguridad si se modifica la lógica F o la estructura del DB de interfaz. | Cargar la seguridad cada vez que se cambia un temporizador o una condición de enclavamiento en el programa normal. |
| Normativa (IEC 61508) | Garantiza la "Ausencia de retroactividad": el fallo del software normal no compromete la lógica segura. | Código donde la seguridad depende de bloques de datos inestables del programa estándar. |
Conclusión
Calidad es Aislamiento. En definitiva, programar en entornos de seguridad no solo se trata de que el motor se detenga cuando se pulsa la seta de emergencia. Se trata de diseñar un sistema robusto, predecible y que cumpla con la normativa internacional. Aislar el programa de seguridad mediante DBs de interfaz es el primer paso para pasar de ser un "tiracables" digital a ser un Ingeniero de Automatización 4.0.
🚀 ¡Próximo Lanzamiento: Especialización en Seguridad TIA Portal!
¿Te ha parecido útil esta arquitectura? Esto es solo la punta del iceberg. Muy pronto en OneDoor estrenaremos nuestro nuevo curso: "Seguridad Funcional y Programación Fail-Safe en TIA Portal".
Aprenderás desde cero:
- Configuración de hardware de seguridad.
- Programación avanzada de bloques F.
- Gestión profesional de firmas y validación según normativa.
📩 ¡No te pierdas nada!
Si quieres ser el primero en enterarte de la fecha de lanzamiento y recibir tips técnicos como este directamente en tu correo: 👉 Suscríbete a nuestra Newsletter
¿Y tú? ¿Cómo gestionas el intercambio de señales en tus proyectos? ¿Usas DBs intermedios o eres de los que se arriesgan a que el Checksum cambie en el peor momento? ¡Déjanos tu comentario abajo y debatamos! 👇