ES2809498T3 - Procedimiento y sistema para diagnosticar averías de transmisión en una red según el estándar opc ua - Google Patents

Procedimiento y sistema para diagnosticar averías de transmisión en una red según el estándar opc ua Download PDF

Info

Publication number
ES2809498T3
ES2809498T3 ES14722594T ES14722594T ES2809498T3 ES 2809498 T3 ES2809498 T3 ES 2809498T3 ES 14722594 T ES14722594 T ES 14722594T ES 14722594 T ES14722594 T ES 14722594T ES 2809498 T3 ES2809498 T3 ES 2809498T3
Authority
ES
Spain
Prior art keywords
data
network
packets
network element
diagnostic
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES14722594T
Other languages
English (en)
Inventor
Sven Kerschbaum
Matthias Heller
Frank Volkmann
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Siemens Corp
Original Assignee
Siemens AG
Siemens Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG, Siemens Corp filed Critical Siemens AG
Application granted granted Critical
Publication of ES2809498T3 publication Critical patent/ES2809498T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/12—Network monitoring probes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0677—Localisation of faults
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823—Errors, e.g. transmission errors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823—Errors, e.g. transmission errors
    • H04L43/0847—Transmission error
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/32—Flooding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/50—Testing arrangements

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)
  • Maintenance And Management Of Digital Transmission (AREA)

Abstract

Procedimiento para diagnosticar averías en la transmisión en una red de datos (NET), incluyendo la red de datos al menos una primera clase de elementos de red (SPS1, 2, 3, HMI1), que envían y/o reciben paquetes de datos (DATA_RT) exclusivamente según un estándar de transmisión de datos para realizar comunicación en tiempo real, según el estándar PROFINET RT, con elevada prioridad y sincronizados en el tiempo y una segunda clase de elementos de red (PC, MES) que envían y/o reciben paquetes de datos (DATA_NRT) no o no exclusivamente según un estándar de transmisión de datos para realizar comunicación en tiempo real, caracterizado porque cuando se pierden paquetes de datos de la primera clase (DATA_RT), se introducen en la red de datos, selectivamente, paquetes de datos de diagnóstico (D_DATA) con la más baja prioridad no o no exclusivamente según el estándar de transmisión de datos para realizar comunicación en tiempo real tal que se conoce la trayectoria de los paquetes de datos de diagnóstico a través de la red de datos y la red de datos se inunda selectivamente con paquetes de datos de diagnóstico (D_DATA), tal que se logra un grado de ocupación de la red de datos del 100 %, con las siguientes etapas: - Enviar un paquete de datos de diagnóstico (D_DATA) desde un primer elemento de red (MES, HMI1, PG, SPS, ⋯) a un segundo elemento de red, - determinar si el paquete de datos de diagnóstico se recibe en el segundo elemento de red, - cuando el paquete de datos de diagnóstico tiene perturbaciones: - determinar todos los puertos del elemento de red (P-⋯) que son atravesados por el paquete de datos de diagnóstico en la trayectoria desde el primer elemento de red hasta el segundo elemento de red y marcar esos puertos como potencialmente averiados y - cuando el paquete de datos de diagnóstico no tiene perturbaciones: - determinar todos los puertos del elemento de red (P-⋯) que son atravesados por el paquete de datos de diagnóstico en la trayectoria desde el primer elemento de red hasta el segundo elemento de red y eliminar de esos puertos la marca como potencialmente averiados.

Description

DESCRIPCIÓN
Procedimiento y sistema para diagnosticar averías de transmisión en una red según el estándar opc ua PROFINET (Process Field Network, red de campo para procesos) es el estándar industrial abierto de Ethernet de Profibus & Profinet International (PI) para la automatización. PROFINET utiliza estándares TCP/IP e IT, puede funcionar en Ethernet en tiempo real y permite la integración de sistemas de bus de campo. Se trata de un protocolo industrial capaz de funcionar en tiempo real que con el tiempo se ha difundido muy ampliamente para transmitir datos de proceso.
Se diferencia entre PROFINET IRT (Isochronous-Real-Time, tiempo real isócrono) y RT (Real Time, tiempo real). PROFINET IRT ofrece, contrariamente a RT, capacidad de estricto tiempo real.
La comunicación PROFINET IRT está compuesta por una parte de comunicación isócrona en tiempo real y una parte de comunicación no en tiempo real (Non-Real-Time, NRT). La parte IRT está planificada con antelación, al asignarse ranuras de tiempo a diversos emisores. No obstante, esta zona de tiempo no llena en un 100% la zona de tiempo disponible (por cada ciclo). El resto puede utilizarse para tráfico NRT. La comunicación IRT se caracteriza, entre otras, por las siguientes particularidades:
La transmisión de los datos se realiza en intervalos de tiempo equidistantes. Cada intervalo de tiempo se divide en un intervalo IRT (canal IRT) y un intervalo abierto (canal abierto). Al inicio de cada intervalo de tiempo se realiza una sincronización en el tiempo.
Una trama (frame) IRT se caracteriza por su posición en el tiempo dentro del canal IRT. La sincronización en el tiempo se realiza en IRT con ayuda del protocolo de precisión de reloj transparente (Precision Transparent Clock Protocol, PTCP) o bien PTP (según IEEE 1588).
Para garantizar las exigencias en cuanto a tiempo, se necesitan conmutadores (switches) especiales. Mediante la sincronización en el tiempo, se comunica a todos los conmutadores el instante de arranque para dar el paso a telegramas IRT.
Cuando se utiliza PROFINET IRT, se fija con la máxima precisión para toda la red (todos los abonados IRT) offline previamente, mediante la herramienta de ingeniería utilizada (por ejemplo el llamado portal TIA ofrecido por la firma Siemens), el envío de los datos de proceso según una secuencia exacta fijada. La máxima desviación permitida del comienzo de un ciclo de bus es de 1 ps. Por lo tanto en la comunicación no existe ningún tiempo de espera. Para esta transmisión de datos ajustada para el máximo rendimiento, han de tomarse precauciones especiales de hardware PROFINET IRT, en particular controladores de Ethernet, que son adecuados para apoyar la sincronización de reloj.
Mediante la planificación previa de la parte IRT y la vigilancia mediante el hardware IRT, queda excluido que la parte de comunicación IRT se vea perturbada por NRT.
En secciones de comunicación que no precisan de ninguna comunicación IRT, puede combinarse la red con componentes de red estándar, no presuponiendo PROFINET RT ningún hardware especial. Sobre estas secciones de comunicación puede utilizarse comunicación PROFINET RT.
Pero debido a ello tampoco se realiza ninguna planificación previa, ya que ello presupondría una vigilancia de los intervalos de tiempo mediante el hardware. PROFINET RT utiliza más bien los mecanismos estándar definidos por IEEE 802.3. De esta manera se logra que PROFINET RT pueda coexistir con comunicación Ethernet estándar (NRT) y el correspondiente hardware. La comunicación RT debe transmitirse con preferencia respecto a la comunicación estándar, para que la comunicación RT pueda cumplir con las exigencias de tiempo real; evidentemente son menores estas exigencias que las de IRT. Esta preferencia se logra utilizando los niveles de prioridad de Ethernet.
Puesto que en PROFINET RT la separación entre comunicación RT y NRT no es tan efectiva como en PROFINET IRT, deben formularse exigencias a la comunicación NRT, aún cuando IEEE 802.3 no las exija.
PROFINET exige de todos los participantes que no envíen más de 3 Kbyte/mseg. En IEEE 802.3 por el contrario no existe unja tal exigencia, existiendo más bien ampliaciones contrarias a esa exigencia, por ejemplo, la llamada transmisión Burst-Mode (modo de ráfagas) o Jumbo-Frames, es decir, frames no estandarizadas y de gran tamaño.
Ello puede dar lugar entonces a que se rechacen frames RT al desbordarse las colas de espera en los elementos de red, ya que el componente de red por ejemplo está bloqueado debido a Jumbo-Frames recién transmitidos de la comunicación NRT. La comunicación RT ya no puede mantenerse entonces correctamente, con lo que en consecuencia la tarea técnica de automatización subyacente ya no puede ejecutarse libre de faltas. Es difícil diagnosticar esta problemática en la red real, ya que las posibilidades de diagnóstico en la red (por ejemplo, mediante SNMP - Simple Network Management Protocol, protocolo simple de administración de red) son demasiado lentas 'para ello.
En un caso se construiría una red PROFINET RT para transmitir los datos en tiempo real en una instalación industrial. En el curso de la vida útil de la instalación se ampliaría la instalación, cuando se realizase el mantenimiento, en componentes para transmitir contenidos de pantalla mediante VNC (Virtual Network Computing, informática virtual en red). VNC es un software conocido en general que muestra el contenido de la pantalla de un ordenador remoto (server o servidor) en un ordenador local (client o cliente) y envía en sentido contrario movimientos del teclado y del ratón del ordenador local al ordenador remoto. Esto da lugar a que la instalación quede parada esporádicamente, con elevados costes para el cliente. La razón de la parada era la transmisión en ráfaga de los contenidos de la pantalla, que ha originado la pérdida de frames RT en un componente de red.
Se generan costes elevados al resultar complejo y pesado el diagnóstico o averiguación del causante de la avería. Para encontrar al causante se registraron durante mucho tiempo de funcionamiento protocolos de red en diversos puntos de la red y se confeccionaron análisis SNMP. Puesto que las informaciones SNMP, como por ejemplo pérdida de paquetes y anchura de banda, se promedian cíclicamente a lo largo de un intervalo de tiempo mayor, esto da lugar a que las ráfagas (bursts) que se presentan ya no se perciban como tales. Las mismas se "diluyen" a lo largo de varios registros. Con ayuda de herramientas de registro en la red, como por ejemplo Wireshark y SNMP-Clientes, se intenta así entender el comportamiento en la red.
Por el documento US 2003/0149919 A1 se conoce ya un procedimiento para diagnosticar averías de transmisión en una red de datos, en particular con protocolo IP, realizándose el diagnóstico de la falta por ejemplo mediante SNMP Polling (consulta remota síncrona).
Las exigencias ampliadas de PROFINET RT no pueden detectarse mediante el sistema (la propia red). Además el software/hardware estándar, como por ejemplo VNC o videocámaras, presta atención exclusivamente al cumplimiento de la exigencia de Ethernet estándar (IEEE 802.3), pero no al cumplimiento de exigencias IRT.
Hasta ahora se percibía y analizaba el problema sólo cuando se daba cuenta el operador de la instalación (parada de la instalación), para eliminar la falta o la fuente de averías. Cuando la instalación se encuentra en la fase de producción, no son de esperar variaciones en la red, a excepción de la introducción de aparatos adicionales para mantenimiento y diagnóstico. Los costes más importantes no los origina la primera aparición aislada del problema, sino más bien el pesado diagnóstico para encontrar la fuente de la avería.
Es por lo tanto objetivo de la invención indicar un procedimiento que permita determinar lo más rápidamente posible dónde se encuentra la fuente de la avería.
El objetivo se logra mediante un procedimiento según las características de la reivindicación 1.
El objetivo se logra además mediante un sistema según las características de la reivindicación 9.
El procedimiento diagnostica perturbaciones en la transmisión en una red de datos, incluyendo la red de datos al menos una primera clase de elementos de red, que envían y/o reciben paquetes de datos exclusivamente según un estándar de transmisión de datos para realizar comunicación en tiempo real, el estándar PROFINET RT y una segunda clase de elementos de red que envían y/o reciben paquetes de datos no o no exclusivamente según un estándar de transmisión de datos para realizar comunicación en tiempo real, introduciéndose paquetes de datos de diagnóstico, selectivamente, en la red de datos e inundándose selectivamente la red de datos con paquetes de datos de diagnóstico, tal que se logra un grado de ocupación de la red de datos del 100 %.
Puesto que al presentarse el problema se desechan paquetes PROFINET RT, que tienen una alta prioridad, se desechan en particular también todos los paquetes con menor prioridad.
La red se inunda, para lograr el diagnóstico rápido, con paquetes de la más baja prioridad, precisamente tal que la red queda ocupada casi en un 100 %. Esta inundación sucede de forma orientada entre un conjunto de abonados. Los paquetes "conocen" su trayectoria y contienen un contador que es inequívoco por cada paquete de datos de diagnóstico enviado y que permite por lo tanto determinar cuántos paquetes de datos se han perdido y cuáles son.
Si ahora se pierden paquetes, entonces puede determinarse la existencia de un problema inmediatamente tras presentarse el problema y sin otra pérdida de tiempo. Mediante análisis adicionales de los paquetes de datos de diagnóstico que faltan, ventajosamente por medio de los contadores incluidos en los paquetes de datos de diagnóstico, puede realizarse una detección de los componentes de red en los que se ha presentado la perdida de paquetes.
Cuando se han encontrado varios puntos de fallo, puede deducirse en base a ello la vía que han recorrido los paquetes de datos de diagnóstico perturbados, o al menos el primer y el último conmutador (switch) y con ello identificarse en definitiva según el procedimiento reivindicado la fuente de la avería con elevada seguridad.
En el siguiente ejemplo de ejecución, que no ha de entenderse limitativamente, se indica el análisis de la medición cruzada de radio a modo de ejemplo en pseudocódigo:
1 Inicialización del conjunto de puertos averiados: S= { }
2 Para cada enlace de comunicación de la medición cruzada (inicio, destino)
3 ¿Está averiado el enlace de comunicación inicio ^ destino?
4 Si ES sí, existe avería:
5 Agregar todos los puertos que retransmiten paquetes del enlace de comunicación desde el inicio hasta el destino al conjunto de puertos averiados S, ya que en estos puertos puede existir potencialmente una avería.
6 CASO CONTRARIO no, no existe avería:
7 retirar todos los puertos que retransmiten paquetes del enlace de comunicación desde el inicio hasta el destino del conjunto de puertos averiados S, ya que en estos puertos con una probabilidad muy grande no puede existir ninguna avería.
8 el conjunto de los puertos averiados S contiene ahora todos los puertos que están averiados. En base a los puertos, puede así concluirse inmediatamente qué aparatos están averiados.
Este procedimiento detecta las pérdidas de paquetes que ocurren en la red ventajosamente de forma inmediata y detecta a la vez la/s fuente/s de avería causante/s.
Se evita así la pesada búsqueda de la fuente de la avería, que genera las grandes pérdidas monetarias debidas a fallos de gran alcance de la red de datos.
Mediante la rápida identificación de la fuente de la avería, pueden además excluirse rápidamente también otros componentes sospechosos de ser los causantes.
A continuación, se describirá la invención mediante figuras:
Figura 1 muestra una estructura de red que funciona actualmente con PROFINET RT,
figura 2 muestra un PG alojado en la estructura de red de la figura 1 con una comunicación VNC (transmisión de pantalla) desde el HMI1 al PG,
figura 3 muestra la transmisión de datos VNC de la figura 2 que origina perturbación del tráfico RT y figura 4 muestra la detección de la avería mediante “medición cruzada” según el procedimiento reivindicado.
La red de datos NET está compuesta aquí por varios nodos de conmutación, también denominados switch, SW1 - SW4, conectados entre sí. A través de estos elementos de red realizan intercambio entre sí los otros elementos de red conectados. En el ejemplo representado en la figura 1 se trata al respecto de varios sistemas de control programables en memoria SPS1 - SPS3 de un sistema de automatización. Además, un Manufacturing Execution System (sistema de ejecución de la fabricación) MES, una interfaz de usuario Human Machine HMI1 y otro aparato PC.
Dos de los sistemas de control programables en memoria SPS1 y SPS3 intercambian paquetes de datos DTA_RT, siendo clara la trayectoria del paquete de datos dentro de la red como sigue: SW2 - SW1 -SW3.
En la figura 2 se introduce a continuación otro aparato de red PG en la red de datos ya descrita en la figura 1, por ejemplo para ejecutar trabajos de mantenimiento procedentes en el sistema de automatización que sirve de base. El mismo envía igualmente un tráfico de datos DATA_IRT a través de otra vía definida dentro de la red: SW1 - SW3 - SW4.
En un ejemplo se utiliza ahora el Virtual Network Computing, abreviadamente VNC. Al respecto se trata de un software que muestra el contenido de la pantalla de un ordenador remoto (server) en un ordenador local (client) y envía en sentido contrario movimientos del teclado y del ratón del ordenador local al ordenador remoto. Con ello, uno puede trabajar sobre un ordenador remoto como si se sentase directamente delante. En la figura 3 se representa que, debido al VNC, se transmiten en una ráfaga un número inusualmente grande de paquetes de datos no planificados, ya que se ha presentado un suceso inesperado.
Puesto que los elementos de red SW1 y SW3 tienen que gestionar tanto el tráfico de datos regular entre SPS1 y SPS3 como también los paquetes de datos que genera el VNC, resultan aquí perturbaciones en la transmisión de datos.
La figura 4 muestra, basándose en la situación descrita en la figura 3, cómo mediante el procedimiento correspondiente a la invención se inunda toda la red NET con paquetes de datos de diagnóstico D_DATA. Complementariamente se representan y diferencian los respectivos elementos de red ventajosamente con puertos de datos adicionales P-PC, P-MES, P-etc., es decir, atributos adicionales de direccionamiento. Puede verse por ejemplo que el tráfico de datos del protocolo VNC, DATA_IRT, del elemento de red SW3 se conduce a través del puerto P_SW33 y por el contrario el otro tráfico de datos DATA_RT se sigue conduciendo a través del puerto P_SW31.
El siguiente ejemplo se basa sólo en los elementos de red, pero no en la información de puertos.
La tabla muestra en qué enlaces “flooding” (de inundación) se pierden paquetes. Al respecto se listan en esta tabla sólo los correspondientes puntos terminales de los enlaces, es decir, emisor y receptor.
Figure imgf000005_0001
De esta tabla y del conocimiento de la red de datos que sirve de base, puede deducirse ahora que los elementos de red/conmutadores SW1, SW3 y SW4 (no incluidos en la tabla) se ven afectados.
Observando el enlace PC-MES se ve que ciertamente transcurre a través del conmutador SW1 realmente afectado, pero se utilizan aquí otros puertos emisores y receptores distintos de la “fuente de perturbaciones”, con lo que este enlace no se toma como averiado.
Bajo la hipótesis de que los conmutadores disponen de una cola de envío por cada puerto, resulta además también un sentido de envío del que puede deducirse que la fuente de la avería tiene que estar conectada a SW1 y el sumidero de la avería tiene que ser el panel HMI.
Esto puede detectarse al no ser simétrica la tabla: Así se ha señalado el enlace de PC a HMI1 como averiado, pero la vía de retorno de HMI a PC, no.
Con esta información queda claro que la fuente de la avería ha de ser bien el PC1 o bien el PG. Analizando más con ayuda de SNMP, el Simple Network Management Protocol (protocolo simple de administración de red) en el conmutador SW1, puede ahora identificarse claramente el elemento de red PG como fuente inicial de la avería.
El análisis de la tabla de resultados de la medición cruzada de radio puede evaluarse también de forma automatizada mediante un programa. El algoritmo para el análisis se indicó ya bastante más arriba en forma de pseudocódigo.
Lista de referencias
DATA_NRT Data Non-Realtime (dato no en tiempo real)
DATA_RT Data Realtime (dato en tiempo real)
F filtro
HMI1 Human Machine Interface (interfaz humano máquina)
HW AP Hardware PROFINET Access Plug (enchufe de acceso ...)
MES Manufacturing Execution System (sistema de ejecución de la fabricación)
NET red
P ... puerto de comunicación de un elemento de red
PC Personal Computer
PG aparato de fabricación
SW2, 3, 4 switch (conmutador)
SP1, 2, 3 sistema de control programable en memoria
S memoria

Claims (9)

REIVINDICACIONES
1. Procedimiento para diagnosticar averías en la transmisión en una red de datos (NET), incluyendo la red de datos al menos una primera clase de elementos de red (SPS1, 2, 3, HMI1), que envían y/o reciben paquetes de datos (DATA_RT) exclusivamente según un estándar de transmisión de datos para realizar comunicación en tiempo real, según el estándar PROFINET RT, con elevada prioridad y sincronizados en el tiempo y una segunda clase de elementos de red (PC, MES) que envían y/o reciben paquetes de datos (DATA_NRT) no o no exclusivamente según un estándar de transmisión de datos para realizar comunicación en tiempo real,
caracterizado porque cuando se pierden paquetes de datos de la primera clase (DATA_RT), se introducen en la red de datos, selectivamente, paquetes de datos de diagnóstico (D_DATA) con la más baja prioridad no o no exclusivamente según el estándar de transmisión de datos para realizar comunicación en tiempo real tal que se conoce la trayectoria de los paquetes de datos de diagnóstico a través de la red de datos y la red de datos se inunda selectivamente con paquetes de datos de diagnóstico (D_DATA), tal que se logra un grado de ocupación de la red de datos del 100 %, con las siguientes etapas:
- Enviar un paquete de datos de diagnóstico (D_DATA) desde un primer elemento de red (MES, HMI1, PG, SPS, ...) a un segundo elemento de red,
- determinar si el paquete de datos de diagnóstico se recibe en el segundo elemento de red, - cuando el paquete de datos de diagnóstico tiene perturbaciones:
- determinar todos los puertos del elemento de red (P-...) que son atravesados por el paquete de datos de diagnóstico en la trayectoria desde el primer elemento de red hasta el segundo elemento de red y marcar esos puertos como potencialmente averiados y
- cuando el paquete de datos de diagnóstico no tiene perturbaciones:
- determinar todos los puertos del elemento de red (P-...) que son atravesados por el paquete de datos de diagnóstico en la trayectoria desde el primer elemento de red hasta el segundo elemento de red y eliminar de esos puertos la marca como potencialmente averiados.
2. Procedimiento según la reivindicación 1,
caracterizado porque para detectar el componente de red (PG) que provoca las averías en la transmisión, se realiza una evaluación en base a los paquetes de datos de diagnóstico (D_DATA) recibidos.
3. Procedimiento según una de las reivindicaciones precedentes,
caracterizado porque para detectar el componente de red (PG) que provoca las averías en la transmisión, se realiza una evaluación en base a los paquetes de datos de diagnóstico (D_DATA) que se han perdido.
4. Procedimiento según la reivindicación 2 ó 3,
caracterizado porque los paquetes de datos de diagnóstico (D_DATA) contienen un primer campo de datos con un respectivo contador inequívoco, un segundo campo de datos con una dirección de inicio y un tercer campo de datos con una dirección de destino.
5. Procedimiento según una de las reivindicaciones precedentes,
caracterizado porque cuando se detecta el componente de red (PG) que provoca las averías en la transmisión, se determinan al menos dos componentes de red que originan la pérdida de paquetes de datos de diagnóstico (D_DATA) en la trayectoria que han recorrido los paquetes de datos de diagnóstico y se cierran.
6. Procedimiento según la reivindicación 5,
caracterizado porque cuando se detecta el componente de red (PG) que provoca las averías en la transmisión, se determinan al menos dos trayectorias y en base a esas trayectorias determinadas, se forma una intersección.
7. Procedimiento según la reivindicación 1,
caracterizado porque en base a los puertos del elemento de red (P-...) marcados, se determina un elemento de red averiado.
8. Procedimiento según una de las reivindicaciones precedentes,
caracterizado porque los paquetes se envían a través de la red según el estándar OPC-UA.
9. Sistema para diagnosticar averías en la transmisión en una red de datos (NET), incluyendo el sistema un equipo para el diagnóstico e incluyendo el sistema una red de datos, incluyendo la red de datos una primera clase de elementos de red (SPS1, 2, 3, HMI1), que envían y/o reciben paquetes de datos (DATA_RT) exclusivamente según un estándar de transmisión de datos para realizar comunicación en tiempo real, según el estándar PROFINET RT y una segunda clase de elementos de red (PC, MES) que envían y/o reciben paquetes de datos (DATA_NRT) no o no exclusivamente según un estándar de transmisión de datos para realizar comunicación en tiempo real,
caracterizado porque el equipo está configurado para realizar uno de los procedimientos según las características de las reivindicaciones 1 a 8.
ES14722594T 2014-04-23 2014-04-23 Procedimiento y sistema para diagnosticar averías de transmisión en una red según el estándar opc ua Active ES2809498T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2014/058191 WO2015161871A1 (de) 2014-04-23 2014-04-23 Verfahren und vorrichtung zur diagnose von übertragungs-störungen in einem netzwerk gemäss opc ua standard

Publications (1)

Publication Number Publication Date
ES2809498T3 true ES2809498T3 (es) 2021-03-04

Family

ID=50685881

Family Applications (1)

Application Number Title Priority Date Filing Date
ES14722594T Active ES2809498T3 (es) 2014-04-23 2014-04-23 Procedimiento y sistema para diagnosticar averías de transmisión en una red según el estándar opc ua

Country Status (5)

Country Link
US (1) US20170048122A1 (es)
EP (1) EP3092748B1 (es)
CN (1) CN106233666B (es)
ES (1) ES2809498T3 (es)
WO (1) WO2015161871A1 (es)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11175643B2 (en) * 2015-08-11 2021-11-16 Siemens Aktiengesellschaft Rich contextualization of automation data
WO2017092879A1 (de) 2015-11-30 2017-06-08 Siemens Aktiengesellschaft Verfahren zur industriellen kommunikation über tsn
EP3425865B1 (de) * 2017-07-05 2019-12-18 Siemens Mobility GmbH Verfahren und vorrichtung zur rückwirkungsfreien unidirektionalen übertragung von daten an einen abgesetzten anwendungsserver
WO2019007516A1 (de) * 2017-07-06 2019-01-10 Siemens Aktiengesellschaft Verfahren zur performanten datenübertragung in einem datennetz mit teilweise echtzeit-anforderungen und vorrichtung zur durchführung des verfahrens
CZ309016B6 (cs) * 2020-06-05 2021-11-24 ŠKODA AUTO a.s. Způsob vzdálené diagnostiky sítě PROFINET a síť PROFINET využívající tento způsob
CN115796033B (zh) * 2022-11-30 2025-03-18 云南电网有限责任公司电力科学研究院 输电系统故障的诊断方法、装置、计算机设备及存储介质

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7237138B2 (en) * 2000-05-05 2007-06-26 Computer Associates Think, Inc. Systems and methods for diagnosing faults in computer networks
US7239611B2 (en) * 2003-03-03 2007-07-03 Microsoft Corporation Controlling admission of data streams onto a network based on end-to-end measurements
US7403486B2 (en) * 2003-10-31 2008-07-22 Acterna Signal level measurement and data connection quality analysis apparatus and methods
DE602005025779D1 (de) * 2005-11-11 2011-02-17 Accenture Global Services Gmbh Verwaltungsystem und -verfahren für Ende-zu-Ende Test und Diagnose
US8782771B2 (en) * 2007-06-19 2014-07-15 Rockwell Automation Technologies, Inc. Real-time industrial firewall
US8130656B2 (en) * 2007-08-07 2012-03-06 Motorola Solutions, Inc. Method and device for routing mesh network traffic
CN101821990B (zh) * 2007-10-09 2012-10-31 Lm爱立信电话有限公司 处理网络中的故障的结构和方法
DE102007062986B4 (de) * 2007-12-21 2013-12-24 Abb Research Ltd. Verfahren und Einrichtung zur Client-Server-Kommunikation gemäß dem Standardprotokoll OPC UA
CN102918820B (zh) * 2010-05-25 2015-11-25 西门子公司 在自动化网络的两个设备之间交换数据的方法和装置
WO2012103125A1 (en) * 2011-01-24 2012-08-02 Abb Inc. Method for analyzing and diagnosing large scale process automation control systems

Also Published As

Publication number Publication date
EP3092748A1 (de) 2016-11-16
EP3092748B1 (de) 2020-06-24
WO2015161871A1 (de) 2015-10-29
US20170048122A1 (en) 2017-02-16
CN106233666A (zh) 2016-12-14
CN106233666B (zh) 2019-12-10

Similar Documents

Publication Publication Date Title
EP3739814B1 (en) Indirect testing using impairment rules
CN101521603B (zh) 一种快速检测链路连通性的方法及系统
CN106233666B (zh) 根据opc ua标准诊断网络中的传输故障的方法和装置
CN104917641A (zh) 一种用于测试丢包的方法、测试设备和系统
WO2018001326A1 (zh) 故障信息获取方法及装置
ES2893656T3 (es) Método para inspección profunda de datos sobre un bus de banda ancha del campo de Internet industrial
US10924378B2 (en) System and method for loopback and network loop detection and analysis
JP6836692B1 (ja) データ収集管理装置およびデータ収集システム
JP4769609B2 (ja) スイッチ装置
US20140156867A1 (en) Offload processing interface
JP4861293B2 (ja) 通信装置、通信方法および通信プログラム
CN118475886A (zh) 用于提供时间关键的控制应用的方法和系统
US8976809B2 (en) Communication system, monitoring device of ring network, and flow rate monitoring method of ring network
US10103933B2 (en) Detection of a faulty node in a network
US10833889B2 (en) Method and device for monitoring control systems
ES2450469T3 (es) Dispositivo de protección de acceso para una red de automatización
WO2016091019A1 (zh) 一种特征数据报文的流量统计和分析方法及相应设备
US10541944B1 (en) High integrity AFDX switches
CN105959129B (zh) 监测网络故障的方法及装置
US11635748B2 (en) Analysis of event based behavior of end-points in an industrial system
ES2266570T3 (es) Transmision de telegramas de datos con sustitucion de datos en el nudo de acoplamiento.
US10547524B2 (en) Diagnostic transparency for on-premise SaaS platforms
WO2005060168A1 (ja) 通信制御システム
CN106257362B (zh) 事件和数据的活动报告
JP2006211173A (ja) ネットワーク監視プログラム及びネットワークシステム