← ComputingSphere

Analizador y decodificador de protocolo DNP3

Su captura ya sabe qué le pasa a la RTU. Nosotros hacemos que lo diga.

Suba un pcap. En minutos, cada RTU tiene un veredicto, cada problema está escrito en palabras claras y el informe sale en el formato de su equipo — con cada mensaje decodificado debajo para probarlo.

Vea lo que encuentra ↓

Plan Free: 1.000 mensajes DNP3 al mes · sin tarjeta de crédito · hecho y alojado en Suecia

Resumen ejecutivo de un informe de ComputingSphere DNP3: veredicto RECHAZADO y cuatro hallazgos para una RTU
Un informe real: una RTU detrás de un gateway de subestación con 13 RTUs, cuatro hallazgos, veredicto Rechazado.
  • Por RTUveredicto y hallazgos, incluso con 30 RTUs detrás de un gateway
  • Byte a byteenlace, transporte, aplicación, IIN y puntos
  • TCP incluidoretransmisiones, resets y reconexiones, con el motivo
  • Su informesu portada, sus secciones, las plantillas de su equipo

Hallazgos automáticos

Los problemas se encuentran por usted, RTU por RTU

Cada RTU de la captura recibe un veredicto — OK, Atención o Rechazado — y una lista de hallazgos escrita para que la entiendan tanto el ingeniero de puesta en marcha como el cliente. ¿Treinta RTUs detrás de un gateway? Una tabla, con las que lo necesitan primero.

  • Reloj detenido

    La RTU informó la misma hora en lecturas diferentes — las marcas de tiempo de sus eventos no son confiables.

  • Reloj con deriva

    El reloj de la RTU se aleja del reloj del maestro entre dos sincronizaciones.

  • Sincronización no aplicada

    La RTU pidió hora (IIN1.4) y el maestro no la corrigió antes del final de la captura.

  • Búfer de eventos lleno

    Eventos perdidos antes de que el maestro los leyera (IIN2.3) — las alarmas que nunca llegaron al centro de control.

  • Consultas sin respuesta

    Consultas que la RTU nunca respondió, respuestas lentas y confirmaciones atrasadas, contadas y fechadas.

  • Comandos fallidos

    SELECT/OPERATE y operación directa rechazados, divergentes o fuera de tiempo.

  • Bits IIN que importan

    Función no soportada, reinicio del dispositivo, control local, error de parámetro — cuántas veces, en qué respuestas.

  • Reinicios y reconexiones

    Cada reconexión TCP con su motivo: cerrada por la RTU, por el maestro, reiniciada o desaparecida sin aviso.

Página RTUs: 30 RTUs en un canal, 4 críticas, 15 en atención, 11 OK, cada una con sus hallazgos
La página RTUs de un gateway de subestación: 30 RTUs en un canal TCP, ordenadas por gravedad, hallazgos en la última columna.

Informes personalizables

Informes estandarizados, con el formato de sus plantillas

La plataforma escribe la parte difícil: el veredicto y los hallazgos. Usted completa la portada, sus comentarios y resaltados, y guarda el formato como plantilla del equipo.

  • Su portada — el logo de su organización y los campos que necesita: cliente, contrato, orden de trabajo, versión de firmware.
  • Su veredicto — mantenga el automático o cámbielo, añada hallazgos manuales, cambie el texto, el nivel y el color de cada uno.
  • Sus secciones — resumen, conexión, puntos, IIN, estadísticas de mensajes, salud de la comunicación, polling, eficiencia, registro de mensajes: active, renombre, reordene.
  • Resaltados en cualquier color en los puntos y mensajes que importan, y un comentario bajo cada sección.
  • Plantillas de la organización — Homologación y Diagnóstico de comunicación incluidas; guarde la suya y todo el equipo la usa.
  • Un canal completo en un documento — un capítulo y un veredicto por RTU. Imprima o guarde en PDF, A4.
Editor del informe: veredicto, un hallazgo manual, secciones y colores de resaltado a la izquierda, el documento imprimible a la derecha
El editor a la izquierda, el documento exactamente como se imprime a la derecha.

Referencia de homologación

Guarde el intercambio que aprobó. Compare cada captura posterior.

¿Aprobó una RTU en la puesta en marcha? Guarde ese intercambio como referencia, en las carpetas de su organización. Meses después — tras una actualización de firmware, el cambio de un gateway, un nuevo maestro — compare una captura nueva con ella, campo a campo.

  • Diferencias resaltadas mensaje a mensaje, hasta cada campo de cada capa.
  • Ignore checksums y números de secuencia para ver solo lo que realmente cambió.
  • Elija qué mensaje comparar de cada lado — el emparejamiento por posición es solo el predeterminado.
Página de comparación: el flujo actual junto a la referencia de homologación guardada, con los campos diferentes resaltados
Una captura nueva frente a la referencia de homologación guardada: los campos diferentes en naranja.

Estadísticas de mensajes

Cada mensaje contado y clasificado

Lo que el maestro y la RTU realmente intercambiaron, en números — sin hoja de cálculo, sin filtro de Wireshark.

  • Por grupo/variación y código de función — cuántas veces apareció cada objeto y cada función.
  • Bits IIN — cuántas respuestas trajeron cada bit.
  • Polling — cada tipo de consulta con su intervalo típico, mínimo y máximo, consultas sin respuesta y tiempo de respuesta p50/p90.
  • Eficiencia — polls de clase vacíos, tasa y confirmación de no solicitados, retraso de los eventos, intentos y fallas de SELECT/OPERATE.
  • El canal completo — todas las RTUs detrás de un gateway lado a lado, con los totales del canal.
Página de análisis: veredicto, indicadores, mensajes por grupo/variación y código de función, conteo de bits IIN
El análisis de una RTU: veredicto, indicadores, objetos, funciones y bits IIN.

Tráfico y latencia en el tiempo

Vea cuándo cambió algo, y cuánto tarda la RTU en responder

Una captura de horas es difícil de leer mensaje por mensaje. Los gráficos muestran todo el período a la vez: dónde subió o bajó el tráfico, dónde el maestro tardó más en consultar y qué tan rápido responde realmente cada RTU.

Gráfico del protocolo: cantidad de mensajes a lo largo de una captura de una hora
Mensajes en el tiempo — el tráfico de la RTU a lo largo de una captura de una hora. Añada respuestas no solicitadas, eventos IIN, entradas digitales o reconexiones al mismo gráfico.
Tabla de intervalo de polling con tiempo de respuesta p50 y p90 por tipo de consulta, y el gráfico del intervalo en el tiempo
Latencia — tiempo de respuesta p50/p90 de cada tipo de consulta, consultas sin respuesta y el intervalo de polling a lo largo de la captura.
  • Tiempo de respuesta p50 y p99 de cada RTU en la página RTUs, y el hallazgo "respuestas lentas" cuando una RTU se queda atrás.
  • Tiempo hasta la confirmación en cada segmento TCP, para distinguir una RTU lenta de una red lenta.

Capa TCP

Cuando no es DNP3, vea el TCP de abajo

Muchas "fallas de RTU" son la red. La sesión TCP muestra cada segmento entre maestro y RTU — flags, números de secuencia, ventana — y cuánto tardó el otro lado en confirmar.

  • Retransmisiones, ACKs duplicados, keep-alives, ventana cero y segmentos que faltan en la captura señalados en la propia fila.
  • Historial de reconexiones con el motivo: la RTU la cerró, el maestro la reinició o el enlace simplemente quedó mudo.
  • Salud de la comunicación en el informe: reconexiones, retransmisiones y resets en una línea de tiempo.
Sesión TCP: cada segmento con flags, Seq/Ack, ventana, tamaño, función DNP3 y tiempo de confirmación
Segmento por segmento: la función DNP3 que lleva cada uno y qué tan rápido fue confirmado.

Hasta el byte

Haga clic en un campo, vea sus bytes

Cada mensaje decodificado capa por capa — enlace, transporte, aplicación — con los bits IIN y el valor, la calidad y la hora de cada punto. Haga clic en cualquier campo y sus bytes se iluminan en el hexadecimal.

  • Registre la RTU como dispositivo una vez y cada punto muestra su nombre — en el decodificador, el simulador y el informe.
  • Una RTU o el canal completo: todas las RTUs detrás del mismo gateway en una lista.
Página Protocolo: lista de mensajes, árbol decodificado con el campo seleccionado y sus bytes contorneados en el panel hexadecimal
El campo Función seleccionado en el árbol, su byte contorneado en el hexadecimal.

Marcas en los paquetes

Pinte la RTU que está investigando

En una captura con decenas de conexiones, marque una con un color y una etiqueta — "firmware nuevo", "alimentador 7", "en prueba" — y sígala entre el ruido.

  • Cualquier color, cualquier etiqueta, en todos los paquetes de esa conexión.
  • Hágala permanente y vuelve sola en cada captura futura con el mismo maestro, RTU y puerto.
Inspector con tres conexiones marcadas en colores diferentes
Tres conexiones marcadas en el Inspector, y el panel que lista sus etiquetas.

Simulador de chatter y threshold

Ajuste el filtro antes de tocar el campo

Pase los valores reales de la captura por los filtros de chatter y banda muerta y vea exactamente qué llegaría al operador — y cuánto tráfico ahorraría.

Simulación de chatter de un interruptor: 25 actualizaciones, 5 enviadas, 20 descartadas, 80% de reducción de tráfico
Chatter — un interruptor que cambia 25 veces: 20 actualizaciones bloqueadas, 80% menos tráfico, y el estado real sigue llegando al operador.
Simulación de threshold de una entrada analógica: valores brutos y propagados en el mismo gráfico
Threshold — una entrada analógica con banda muerta de 50 unidades: 16 de 25 actualizaciones descartadas, 64% menos tráfico, valores brutos y propagados en el mismo gráfico.

O ejecute los dos filtros sobre todos los puntos de la RTU a la vez y vea el ranking de los que más tráfico reducirían.

Planes

Suba su primera captura hoy

Cree la cuenta en menos de un minuto, suba un pcap y vea lo que sus RTUs le están diciendo.

Crear una cuenta toma menos de un minuto — regístrate y empieza a usarlo de inmediato.

Cancela cuando quieras, en pocos clics. Tu plan sigue activo hasta el final del período ya pagado.

Sin necesidad de cuenta

Pegue una trama DNP3 y véala decodificada

Este es el mismo analizador que la plataforma ejecuta en cada captura. Pegue hasta 10 tramas DNP3 en hexadecimal a continuación, una por línea, y vea exactamente lo que él ve.