Los eventos DNP3 no llegan en los sondeos de clase
El síntoma: los sondeos de integridad devuelven valores actuales correctos, el enlace está sano, pero los sondeos de clase 1, 2 y 3 regresan vacíos aunque los puntos en campo claramente cambian. Los operadores ven los valores actualizarse solo en el sondeo de integridad lento y el historial de cambios de estado falta. Como DNP3 separa los datos estáticos de los datos de eventos, esta falla casi siempre es configuración en la estación remota o el maestro en vez de una falla de comunicaciones, y tiene una lista corta de causas que vale la pena revisar en orden.
Los eventos DNP3 no llegan en una línea: Cuando los eventos DNP3 no llegan en los sondeos de clase, la estación remota normalmente no está generando eventos en primer lugar. DNP3 solo crea un evento para un punto que está asignado a la clase de evento 1, 2 o 3; los puntos sin asignar producen solo datos estáticos, visibles en los sondeos de integridad pero nunca en los sondeos de eventos. Las siguientes causas en la fila son bandas muertas analógicas tan amplias que los cambios nunca califican, un buffer de eventos que se desbordó y perdió historial, confirmaciones de capa de aplicación faltantes que impiden a la estación remota borrar y enviar eventos frescos, y reporte no solicitado que se supone activo cuando nunca se habilitó en ambos extremos.
Primeras revisiones: asignación de clase y bandas muertas
Empiece en la configuración de puntos de la estación remota, porque la causa más común son puntos que nunca se asignaron a una clase de evento. En DNP3, la clase 0 representa datos estáticos - el valor actual de todo - mientras que las clases 1, 2 y 3 contienen eventos. Un punto asignado a ninguna clase de evento no genera eventos, nunca. La pista de esta causa es exactamente el síntoma descrito: los sondeos de integridad, que incluyen la clase 0, muestran valores cambiantes correctos, mientras que los sondeos de eventos quedan vacíos. Los predeterminados de RTU y gateway difieren, y algunos salen con cada punto sin asignar, así que una instalación nueva que muestra este síntoma casi siempre cae aquí.
Para los puntos analógicos la segunda compuerta es la banda muerta. Una entrada analógica solo genera un evento cuando se mueve más que su banda muerta configurada desde el último valor reportado, que es como DNP3 evita inundar el enlace con ruido. Fije la banda muerta demasiado amplia, ya sea por confusión de unidades en valores de ingeniería escalados o un copiar y pegar de otro tipo de punto, y una señal que normalmente se mueve nunca califica. Compare la banda muerta contra el rango operativo real de la señal: una banda muerta mayor que la excursión normal de la señal significa silencio por diseño. Los puntos binarios no tienen banda muerta, así que si faltan eventos binarios mientras fluyen los analógicos, eso apunta de vuelta a la asignación de clase.
Buffers, confirmaciones y dónde mueren los eventos
Los eventos que se generan deben sobrevivir hasta su entrega, y el buffer de eventos de la estación remota es donde esperan. Los buffers son finitos; cuando uno se llena, la estación remota activa la indicación interna de desbordamiento de buffer y, según la configuración, descarta los eventos más viejos o los más nuevos. Un maestro que sondea rara vez, o un enlace que estuvo caído por un tramo largo, puede por lo tanto perder historial de eventos aunque el sondeo en vivo luego se vea bien. Si sus eventos se pierden en ráfagas que se alinean con interrupciones o con horarios de sondeo lentos, revise el bit de indicación de desbordamiento en las respuestas de la estación remota y el dimensionamiento de buffer por clase.
La entrega también depende del handshake de confirmación de capa de aplicación. Cuando una estación remota envía eventos, pide al maestro que confirme la recepción; solo un evento confirmado puede borrarse de forma segura del buffer. Un maestro que falla en enviar confirmaciones de aplicación deja a la estación remota incapaz de borrar los eventos entregados, lo cual lleva a la retransmisión de los mismos eventos, buffers que nunca drenan, y eventualmente desbordamiento. Los síntomas de un problema de confirmación se ven extraños: eventos duplicados, los mismos eventos repitiéndose en cada sondeo, o entrega de eventos que se degrada con el tiempo. Un analizador de protocolo o el registro de comunicación en cualquiera de los extremos muestra rápido si las confirmaciones fluyen.
Reporte no solicitado: habilitado en ambos extremos o no del todo
Si la intención del diseño era que los eventos llegaran por sí solos, sin esperar un sondeo de clase, el mecanismo es el de respuestas no solicitadas, y debe habilitarse de forma coherente en ambos extremos. La estación remota debe tener el reporte no solicitado habilitado para las clases relevantes, y el maestro debe permitirlo, típicamente enviando una petición de habilitar no solicitados tras conectar. Un desajuste produce exactamente el estado confuso a medio funcionar que genera llamadas de soporte: los eventos llegan solo cuando un sondeo de clase resulta correr, porque la trayectoria no solicitada que todos supusieron funcionando nunca se habilitó en realidad.
También hay una sutileza de arranque: las estaciones remotas comúnmente anuncian su presencia con una respuesta no solicitada nula tras reiniciar y retienen los datos de eventos hasta que el maestro rehabilita el reporte no solicitado. Un maestro que no responde correctamente a esa secuencia de arranque deja a la estación remota esperando cortésmente para siempre. Si los eventos se detienen específicamente tras los reinicios de la estación remota y se reanudan tras un sondeo manual o un reinicio del maestro, este handshake es el lugar a mirar.
Cuándo escalar
Si las asignaciones de clase están confirmadas, las bandas muertas son sensatas, las confirmaciones fluyen, y el no solicitado está configurado de forma coherente, capture el tráfico real antes de llamar al fabricante. DNP3 es observable: una captura que muestre su sondeo de clase y la respuesta vacía de la estación remota, junto con una exportación de la configuración de puntos de la estación remota, permite a un fabricante o integrador resolver en minutos lo que los tickets basados en descripción tardan días en rodear. Anote los bits de indicación interna en cada respuesta: los bits de reinicio, desbordamiento de buffer y error de parámetro cada uno apunta a una causa específica poco glamorosa.
La razón por la que este modo de falla importa operativamente es que los datos de eventos son lo que da a un historial SCADA su resolución entre sondeos. Una plataforma como Merobix que consume eventos DNP3 registra los cambios reales con marca de tiempo del campo, así que cuando los eventos se secan, las tendencias se degradan en silencio a instantáneas lentas. Vigilar esa degradación, y alarmar sobre las indicaciones de desbordamiento de buffer, convierte una pérdida silenciosa de calidad de datos en un elemento de mantenimiento que usted atrapa la semana en que empieza.
Preguntas frecuentes
¿Por qué los sondeos de integridad funcionan mientras los sondeos de clase no devuelven nada?
Porque leen datos distintos. Un sondeo de integridad incluye la clase 0, el valor actual estático de cada punto, que existe sin importar la configuración. Los sondeos de clase 1, 2 y 3 devuelven solo eventos, y los eventos solo existen para puntos asignados de forma explícita a una clase de evento cuyos cambios excedan cualquier banda muerta configurada. Datos estáticos fluyendo mientras los sondeos de eventos quedan vacíos es la firma de puntos no asignados a clases de evento o bandas muertas demasiado amplias.
¿Necesito respuestas no solicitadas para que los eventos DNP3 funcionen?
No. Los eventos se acumulan en el buffer de la estación remota y un sondeo de clase simple los recupera, que es un diseño de eventos sondeados perfectamente válido. Las respuestas no solicitadas agregan entrega espontánea para que el maestro se entere de los cambios sin sondear, lo cual conviene a enlaces de bajo ancho de banda o alta latencia. Lo que rompe las instalaciones es suponer que el no solicitado está activo cuando solo un extremo se configuró para él, así que los eventos se quedan en el buffer hasta que algún sondeo los recoge.
¿Qué pasa cuando un buffer de eventos DNP3 se desborda?
La estación remota activa el bit de indicación interna de desbordamiento de buffer de eventos en sus respuestas y descarta eventos según su configuración, así que se pierde historial aunque los valores actuales sigan correctos. El desbordamiento normalmente significa que los eventos se generan más rápido de lo que se recogen: sondeo demasiado raro, una interrupción de enlace, bandas muertas demasiado estrechas generando cháchara, o confirmaciones que no fluyen de modo que los eventos entregados nunca se borran. El bit de desbordamiento es el diagnóstico, y los maestros deben hacerlo visible en vez de ignorarlo.
Fuentes y lecturas
Referencias primarias de los organismos de normas y reguladores que definen este tema:
- DNP3 (IEEE 1815) Protocol - DNP Users Group
Servicios de automatización
¿Necesita convertir esta información en un sistema que funcione?
Merobix integra SCADA, programa PLC Allen-Bradley y Siemens, y diseña y fabrica tableros de control industrial.
Las solicitudes de reunión se revisan antes de confirmarse.