C135 PCS 7 (PCS7)
6C
6 Cielo Ciencia y Tecnología
·Publicada en C135 PCS 7 (PCS7)

Cómo eliminar alarmas de sistema obsoletas y colgadas de dispositivos de campo eliminados en PCS 7 OS

Para eliminar alarmas de sistema obsoletas o "colgadas" en SIMATIC PCS 7 WinCC OS —donde las alarmas de dispositivos de campo PROFIBUS/PROFINET eliminados permanecen atascadas en la lista de alarmas activas con una marca de tiempo tachada—, utilice el script de restablecimiento oficial de Siemens (Entrada SIOS 109751476) o reinicie la caché de la base de datos de runtime de Alarm Logging. Estas alarmas fantasma ocurren porque el controlador AS transmitió un mensaje de fallo de entrada (COME) antes de que el esclavo de hardware fuera eliminado de HW Config. Una vez que se eliminan el dispositivo y sus bloques de drivers y se vuelven a compilar los drivers de módulo, el AS ya no posee la instancia de bloque para emitir el evento de salida (GO), lo que deja la alarma permanentemente sin reconocer y sin borrar en WinCC.

Índice de contenidos

Causa raíz: Por qué los esclavos de bus de campo eliminados dejan alarmas colgadas

En SIMATIC PCS 7, el seguimiento del estado de las alarmas entre el Sistema de automatización (AS) y la Estación de operador (OS) de WinCC funciona como un protocolo de enlace ("handshake") con estado y basado en eventos:
1. Estado de entrada (COME): Cuando un esclavo de bus de campo (por ejemplo, el esclavo DP 1/14) falla, el bloque de diagnóstico (DP_DIAG o OB_DIAG1) llama a ALARM_8P para transmitir un evento de entrada. WinCC inserta la alarma en su lista activa.
2. Eliminación de hardware: Un ingeniero elimina el esclavo fallido en HW Config, actualiza la imagen de proceso y recompila los diagramas CFC con la opción "Generar drivers de módulo" ("Generate module drivers").
3. La alarma huérfana: El compilador de CFC elimina el bloque de diagnóstico asociado de los diagramas @. Debido a que el bloque ya no existe en el AS, nunca puede evaluar un estado saludable ni enviar el mensaje de salida (GO) a WinCC.
4. Resultado: WinCC Alarm Logging espera un telegrama GO coincidente del número de bloque de origen en el AS. El acuse de operador estándar reconoce el evento, pero la alarma no puede salir de la lista activa sin un estado de salida.

Comprensión del indicador de marca de tiempo tachada

Cuando una alarma muestra una línea horizontal tachada a través de su marca de tiempo o texto de mensaje en la tabla WinCC AlarmControl:
- Evento de salida faltante: El motor de gestión de alarmas indica que la comunicación con el bloque tecnológico de origen se ha interrumpido o la instancia del bloque ha desaparecido mientras la alarma estaba activa.
- Fallo del acuse de emergencia: Intentar un acuse de emergencia (Not-Quittieren) utilizando el número de mensaje interno falla porque el acuse de emergencia solo satisface la marca de acuse del operador; no puede fabricar un estado de salida faltante.

Método 1: Uso de la herramienta oficial de restablecimiento de acuse de Siemens (SIOS 109751476)

Siemens proporciona una solución de ingeniería dedicada documentada en la Entrada SIOS 109751476 ("Resetting hanging messages in PCS 7 OS"):

Paso 1: Descargar e integrar la imagen de restablecimiento

  1. Descargue el paquete PDL de diagnóstico de la entrada SIOS 109751476.
  2. Copie el archivo de imagen proporcionado (por ejemplo, @ResetHangingAlarms.pdl) en el directorio GraCS del proyecto OS en el Servidor OS principal.
  3. Abra Graphics Designer en WinCC Explorer para inspeccionar el script en C interno:
    - El script se conecta a la API de Runtime del Servicio de Mensajes del Open Development Kit (ODK) de WinCC (MSRTSetMsgGone()), la cual inyecta mediante programación un estado GO sintético directamente en el búfer de runtime de Alarm Logging local para números de mensaje específicos.

Paso 2: Ejecutar el restablecimiento en el Runtime de WinCC

  1. En el Runtime de WinCC OS, abra la ventana de navegación e invoque @ResetHangingAlarms.pdl.
  2. La imagen muestra una cuadrícula que enumera todas las alarmas activas actualmente marcadas como huérfanas o atascadas.
  3. Seleccione el mensaje colgante del esclavo DP (por ejemplo, "DP-Slave 1/14: Ausfall").
  4. Haga clic en el botón Reset / Force Gone (Restablecer / Forzar salida).
  5. Resultado: El script emite el telegrama de salida faltante. La alarma desaparece de la lista de alarmas activas (Neuliste) y se mueve al archivo histórico (Archivliste).
  6. Repita la operación en el Servidor OS compañero redundante si la replicación de la base de datos no borra inmediatamente ambos nodos.

Método 2: Restablecimiento de la base de datos de runtime de WinCC Alarm Logging

Si el PDL de restablecimiento no está disponible o si numerosas alarmas obsoletas abarrotan una estación de prueba/puesta en marcha, realice un restablecimiento completo de la caché de la base de datos de runtime:

Flujo de trabajo operativo:

  1. Desactive el Runtime de WinCC en la estación OS afectada.
  2. Cierre WinCC Explorer y abra el Símbolo del sistema de Windows como Administrador.
  3. Termine cualquier proceso de base de datos de WinCC residual ejecutando:
    cmd CCCleaner
  4. Navegue al directorio del proyecto OS en el Explorador de archivos de Windows.
  5. Localice la subcarpeta ArchiveManager\AlarmLogging.
  6. Realice una copia de seguridad y elimine los archivos temporales de caché de segmentos de runtime (*.mdf y *.ldf, que representan el búfer circular activo a corto plazo; no elimine los archivos históricos de copia de seguridad a largo plazo).
  7. Reinicie WinCC Explorer y active el Runtime.
  8. Resultado: WinCC vuelve a crear una caché de alarmas limpia y sincronizada a partir de los estados activos del controlador AS, eliminando por completo los mensajes fantasma de hardware eliminado.

Verificación

Para verificar que las alarmas colgadas se han borrado correctamente:
- Abra la lista de entrada de WinCC AlarmControl en todas las estaciones de operador: confirme que las alarmas de los esclavos DP/PN eliminados ya no aparecen.
- Verifique los archivos de alarmas a corto y largo plazo de WinCC: verifique que el mensaje aparezca con una marca de tiempo de salida artificial (GO) y los metadatos correctos de acuse de operador.
- Active una alarma de proceso o de hardware legítima (por ejemplo, desconecte un módulo de prueba): confirme que las alarmas reales aparecen, se reconocen y se borran limpiamente sin interrupciones.

Limitaciones y precauciones operativas

  • Consideraciones de Process Historian (PH): Si la planta utiliza SIMATIC Process Historian (PH), restablecer manualmente los mensajes mediante la eliminación de la base de datos requiere precaución. Asegúrese de que la base de datos del PH esté sincronizada para evitar alarmas de entrada no coincidentes en la base de datos de informes históricos a largo plazo.
  • Pares de Servidores OS redundantes: Al borrar alarmas en servidores OS redundantes, ejecute siempre el procedimiento primero en el servidor en modo de espera ("standby"), verifique la estabilidad y luego repítalo en el servidor maestro para evitar el seguimiento de alarmas con cerebro dividido ("split-brain").
  • Nunca elimine esclavos mientras las alarmas estén activas: La mejor práctica operativa es reconocer y restaurar físicamente o puentear un esclavo defectuoso antes de eliminarlo del proyecto de HW Config.

Preguntas frecuentes del ingeniero

¿Por qué el acuse de emergencia (Not-Quittieren) no borró la alarma?

El acuse de emergencia solo cumple con el requisito de que un operador ha visto el fallo. No genera el estado tecnológico GO que le informa a WinCC que la condición de fallo físico se ha despejado.

¿El restablecimiento de la caché de Alarm Logging eliminará mis registros históricos de alarmas?

No. Los archivos históricos a largo plazo almacenados en los segmentos de base de datos SQL no se modifican. Solo se reindexa el búfer de runtime activo a corto plazo que contiene los estados actuales.

¿Puede ocurrir este problema con dispositivos PROFINET además de PROFIBUS?

Sí. Cualquier dispositivo distribuido (PROFIBUS DP, PROFINET IO, AS-Interface) cuyos bloques de drivers se eliminen de CFC mientras un estado de alarma está registrado activamente en WinCC puede provocar alarmas colgadas.

¿Dónde puedo encontrar el número de mensaje exacto de la alarma colgada?

En WinCC AlarmControl, configure las columnas de la tabla para mostrar el Número de mensaje (MsgNr). Este número es obligatorio si se apunta al mensaje específicamente a través del script de restablecimiento.

Referencias técnicas

  • Siemens Industry Online Support: Entrada SIOS 109751476 ("Resetting hanging alarms in PCS 7 OS").
  • Entrada SIOS 109742323: PCS 7 Compendium Part A - System Diagnostics and Driver Engineering.
  • Entrada SIOS 109809264: SIMATIC Process Control System PCS 7 Advanced Process Library Manual.
  • Manual de WinCC ODK de Siemens: Working with MSRT Message Service Functions in WinCC Runtime.

Artículos relacionados

Etiquetas relacionadas

  • Alarm Logging
  • WinCC
  • PCS 7
  • PROFIBUS
  • Diagnóstico
  • Alarmas de sistema
  • Automatización industrial
20 respuestas