protocolo industrial

Machine Translated by Google
EtherNet/IP: Libro blanco de protocolo industrial
© Instituto de Ingenieros Eléctricos y Electrónicos, EFTA 2001 Por Paul Brooks Gerente de Marketing Europeo, Adopción de Tecnología Logix/NetLinx
Rockwell Automation Octubre de 2001
Resumen: DeviceNet™ y ControlNet™ son dos conocidas redes industriales basadas en el protocolo CIP (CIP = Control an
Information Protocol). Ambas redes han sido desarrolladas por Rockwell Automation, pero ahora son propiedad y están mantenidas por
las dos organizaciones de fabricantes ODVA (Open DeviceNet Vendors Association) y ControlNet International. ODVA y ControlNet
International han presentado recientemente el miembro más reciente de esta familia: EtherNet/ IP ("IP" significa "Protocolo industrial").
Este documento describe las técnicas y los mecanismos que se utilizan para implementar un conjunto completamente coherente de servicios
y objetos de datos en una red Ethernet® basada en TCP/ UDP/ IP.
I. Introducción Las arquitecturas de automatización deben proporcionar a los usuarios tres servicios principales. El primero, el control, es
el más importante. Los servicios de control implican el intercambio de datos de tiempo crítico entre dispositivos de control, como PLC
y dispositivos de E/S, como variadores de velocidad, sensores y actuadores. Las redes que se encargan de la transmisión de estos
datos deben proporcionar cierto nivel de establecimiento de prioridades y/o capacidades de interrupción. En segundo lugar, las redes
deben proporcionar a los usuarios capacidades de configuración para configurar y mantener sus sistemas de automatización. Esta
funcionalidad generalmente implica el uso de una computadora personal (PC) o una herramienta equivalente para la programación de
varios dispositivos en el sistema. Esto se puede realizar en la comisión y también durante el tiempo de ejecución, como la gestión de
recetas en operaciones por lotes. Por último, una arquitectura de automatización debe permitir la recopilación de datos con fines de
visualización en estaciones MMI, análisis y tendencias, y/o resolución de problemas y mantenimiento. Las redes que pueden
proporcionar los tres servicios ( control, configuración y recopilación de datos ) brindan la mayor cantidad de flexibilidad y eficiencia
para un mejor rendimiento general del sistema. Las redes que se basan en el modelo productor/consumidor , donde los datos se
identifican, en lugar de estar vinculados a direcciones de origen y destino explícitas, pueden admitir el control, la configuración y la
recopilación de servicios de datos. Las capas de aplicación que utilizan objetos distribuidos y servicios de comunicación productor/
consumidor cumplen los requisitos de las arquitecturas de automatización. Al proporcionar estos servicios (la Figura 1 muestra una
arquitectura de automatización típica), no se puede suponer que un solo nivel de red satisfará todos los requisitos de la aplicación, ya
que las capas física y de enlace de datos de cada red tienen sus propios atributos y beneficios. Cuando se requiere una estructura de
red de varios niveles, la arquitectura de red debe proporcionar consistencia de datos entre segmentos de red dispares.
Figura 1: Arquitectura típica de automatización multinivel
De manera similar, cuando estos servicios se brindan en una red Ethernet, no se puede suponer que no se requerirán otros servicios en ese
segmento de red. Los servicios de productor/consumidor deben coexistir completamente con otros servicios que puedan existir en el
segmento de red (por ejemplo, http para páginas web. La arquitectura típica que se muestra en la Figura 1 anterior incluye una red de nivel
de información que puede ser provista por un segmento de red Ethernet, que la mayoría de los proveedores de controladores han estado
proporcionando durante muchos años Tiene un nivel de control, que tradicionalmente tiene atributos valiosos como el determinismo duro y
la redundancia de medios (como ControlNet de ControlNet International) y un nivel de dispositivo que requiere volúmenes de datos bajos
con energía y datos proporcionados en un solo cable de red robusto (como DeviceNet de ODVA). ODVA y ControlNet International han
presentado recientemente el miembro más nuevo de la familia CIP: EtherNet/IP ("IP" significa "Protocolo industrial"). Esto implementa el
conjunto completo de control , configuración y servicios de datos de recopilación de datos en una red Ethernet y, por lo tanto, se pueden
utilizar tanto para los niveles de información como de control en el arquitecto típico ura que se muestra en la Figura 1.
Machine Translated by Google
II. Implementación de CIP en Ethernet La especificación EtherNet/IP está disponible para su descarga gratuita desde ODVA
y los sitios web de ControlNet International además del sitio web de EtherNet/IP. Además de estar subdividido en varios capítulos y anexos, en el
documento se describen las siguientes características:
Figura 2: Alcance de la especificación de EtherNet/IP
Modelado de objetos
explícito y
Implícito (E/S)
Mensajería
Comunicación
Objetos
Objeto general
Biblioteca
Perfiles de dispositivos
Datos electrónicos
Hojas (EDS)
Explícito
Mensajería
Servicios
Datos
administración
Como se puede ver en la Figura 2, la capa de aplicación, las bibliotecas de objetos de aplicación y los perfiles de dispositivos
son consistentes entre EtherNet/IP, DeviceNet y ControlNet. Solo las 4 capas más bajas del modelo OSI de 7 capas (Figura 3) dependen de la red.
Sin embargo, es la forma en que se utilizan esas capas lo que, a su vez, determina la implementación óptima de la recopilación de datos, la
configuración de dispositivos y los servicios de control en EtherNet/IP y hace que sea práctico y seguro usar EtherNet/IP. en el nivel de control. tercero
Convivencia con Internet (y otros)
Protocolos El principal beneficio que la mayoría de los usuarios de EtherNet/IP esperarán obtener será aprovechar la
capacitación y el conocimiento de Ethernet dentro de su empresa y maximizar el retorno de sus inversiones en infraestructuras de Ethernet.
Del mismo modo, buscarán hacer un uso mejor y más efectivo de los componentes Ethernet comerciales listos para usar (COTS) que están
disponibles hoy en día de una amplia variedad de fabricantes de la competencia para reducir el costo de propiedad de sus infraestructuras de red. Estos
beneficios no podrían materializarse si EtherNet/IP requiriera una infraestructura de red separada, personalizada (es decir, no genérica) con medios físicos
especificados por el proveedor. De manera similar, no podrían realizarse si EtherNet/IP requiriera instalaciones de red dedicadas para operar con una
conexión mínima o nula al resto de la infraestructura de la red corporativa. La compatibilidad con los protocolos de Internet e intranet existentes es
imprescindible. Eso significa que TCP/IP estará en todas partes, así que empezaremos por ahí.
A. Protocolos de comunicación utilizados con Ethernet La tecnología Ethernet por sí sola proporciona un conjunto de definiciones de medios
físicos, un esquema para compartir esos medios físicos (CSMA/CD) y un formato de trama simple y un esquema de direccionamiento de
origen/destino para mover paquetes de datos entre dispositivos. en una LAN. Por sí mismo, Ethernet carece de las características más complejas
requeridas de una LAN completamente funcional. Por esa razón, todas las redes Ethernet instaladas admiten uno o más protocolos de
comunicación que se ejecutan sobre Ethernet y brindan funciones sofisticadas de transferencia de datos y administración de redes. Es el protocolo
de comunicación el que determina qué nivel de funcionalidad admite la red, qué tipos de dispositivos se pueden conectar a la red y cómo
interoperan los dispositivos en la red. Algunos de los protocolos que se han implementado a través de Ethernet son DECnet™, Novell IPX™,
MAP™, TOP, la pila OSI, AppleTalk™ y TCP/IP. De estos, TCP/IP está recibiendo la mayor atención debido a la aparición de la Internet global
(incluida la World Wide Web), así como las intranets corporativas que están transformando la forma en que las corporaciones distribuyen la
información internamente. TCP/IP es el protocolo de Internet. Aunque TCP/IP se ejecutará en medios físicos distintos de Ethernet, y Ethernet
admite otros protocolos de comunicación, los dos se han vinculado cada vez más debido al deseo de las organizaciones de integrar a la perfección
sus intranets internas con Internet global. Es seguro decir que TCP e IP son ahora, o pronto serán, los protocolos dominantes de "capa
intermedia" (consulte la Figura 3) que también se ejecutan en redes Ethernet en la planta de producción.
B. Origen y funciones de TCP/IP A lo largo de los años, TCP/IP se ha adaptado a todas las principales plataformas informáticas del mundo.
Actualmente está integrado en cada copia del sistema operativo Windows NT™ y Windows 2000™.
Machine Translated by Google
distribuido, lo que lo convierte en una opción popular para PC en red. Muchas organizaciones tienen una combinación de
estaciones de trabajo, impresoras en red, servidores y computadoras centrales y de rango medio, que rara vez las proporciona un solo
proveedor. TCP/IP está disponible para todos estos dispositivos y es una opción lógica para integrar estos dispositivos en una LAN.
TCP/IP es un protocolo en capas que se puede asignar aproximadamente al modelo de red de 7 capas OSI (consulte la Figura 3). En
este diagrama, Ethernet representa las capas 1 (física) y 2 (enlace de datos). El protocolo de Internet (IP) se asigna a la capa 3 (red).
Los transportes TCP y UDP se asignan a la capa 4 (transporte). Los servicios de usuario comúnmente asociados con las redes TCP/
IP se asignan a la capa 7 (aplicación). El conjunto de protocolos TCP/IP no tiene un mapeo específico a las capas 5 y 6 del modelo.
Figura 3 Modelo OSI de siete capas
Cada capa del modelo OSI utiliza los servicios proporcionados por la capa inmediatamente inferior. Por ejemplo, cuando una
conexión TCP necesita enviar un paquete de datos a otro dispositivo a través de Ethernet, pasa el paquete a IP para su transmisión.
Luego, IP maneja la interfaz a Ethernet y asegura que el paquete se transmita a la red Ethernet al dispositivo de destino. En el
extremo receptor, la capa IP recibe el paquete de la interfaz Ethernet y lo pasa a la conexión TCP adecuada dentro del receptor. La
capa más baja de TCP/IP es la capa de red, donde reside IP. IP proporciona un método sin conexión y sin reconocimiento para
enviar paquetes de datos (datagramas) entre dos dispositivos en una red. IP no garantiza la entrega; se basa en un protocolo de
capa de transporte o capa de aplicación para hacerlo. IP puede ejecutarse a través de Ethernet o de una variedad de otras tecnologías
LAN o WAN (red de área amplia). Esa es una de las razones por las que IP puede mover datos sin problemas desde intranets
corporativas a Internet global. La capa de red también es donde reside el Protocolo de resolución de direcciones (ARP).
ARP se utiliza para asignar direcciones Ethernet a direcciones IP y para mantener tablas de asignación en cada dispositivo de la
red. Cuando un dispositivo quiere transmitir un datagrama IP a otro dispositivo, intenta buscar la dirección Ethernet correspondiente
a esa dirección IP en su tabla ARP interna. Si no existe tal dirección, el protocolo ARP se usa para consultar la red a través de un
mensaje de transmisión local para pedirle al dispositivo con la dirección IP correspondiente que devuelva su dirección Ethernet al
remitente. La respuesta se coloca en una tabla interna y se utiliza para la comunicación posterior. Es importante tener en cuenta que
los mensajes de difusión de Ethernet pasan a través de concentradores, conmutadores y puentes, pero no pasan a través de
enrutadores. Por lo tanto, los mensajes de difusión se limitan a las subredes de Ethernet y no se propagan a Internet en todo el
mundo. Las direcciones IP son cantidades de 32 bits administradas por InterNIC, una autoridad independiente, y deben ser únicas
en cualquier red. Cualquier dispositivo que desee comunicarse fuera de una LAN corporativa cerrada debe usar una dirección IP del
bloque asignado. A diferencia de las direcciones Ethernet, que el fabricante fija en el hardware Ethernet y no se pueden cambiar, el
usuario, de acuerdo con las políticas locales de su departamento de Sistemas de Información corporativo, configura las direcciones
IP y las subredes.
Las direcciones IP se pueden cambiar, pero hacerlo debe hacerse de una manera cuidadosamente planificada para evitar
romper las aplicaciones de red existentes que asumen que un dispositivo en particular está ubicado en una dirección IP en
particular. Si una LAN está conectada a Internet global a través de un enrutador, sus direcciones IP deben seguir las reglas
relacionadas con el uso de direcciones IP del bloque asignado. Las LAN corporativas que no están conectadas a Internet en ningún
momento pueden seguir sus propias reglas con respecto a la asignación de direcciones IP. Las direcciones IP se están agotando a
medida que crece la popularidad de Internet global. Se están tomando medidas para implementar una nueva forma de dirección IP
(conocida como IPv6) que ampliará la cantidad de bits utilizados (a 48 bits) y, por lo tanto, la cantidad de direcciones IP disponibles.
Al igual que las direcciones Ethernet, las direcciones IP pueden ser de unidifusión (destino único), multidifusión (destino de grupo) o
direcciones de difusión (recibidas por todos). Las direcciones IP deben asignarse al tipo de dirección Ethernet compatible adecuado
mediante el software IP y el controlador Ethernet. Los transportes admitidos por el conjunto de protocolos TCP/IP son TCP (Protocolo
de control de transmisión) y UDP (Protocolo de datagramas de usuario). Ambos se asignan a la capa de transporte del modelo OSI.
TCP es un transporte orientado a la conexión que proporciona una transmisión confiable de datos de un dispositivo a otro.
Una vez que se establece una conexión TCP entre dos dispositivos, TCP maneja la fragmentación y el reensamblaje de paquetes
de mensajes, detecta fallas, realiza reintentos y, en general, proporciona una alta calidad de servicio entre los dos dispositivos. TCP
garantiza que los datos pasarán de un dispositivo a otro si es posible. Si la transmisión falla por algún motivo, TCP se asegura de que
las aplicaciones en ambos extremos de la conexión TCP lo sepan. TCP presenta datos a la capa de aplicación por encima de ella en
forma de un flujo de bytes continuo. La solicitud receptora debe ser
Machine Translated by Google
capaz de reconocer cualquier delimitador de mensaje que la aplicación transmisora pueda incorporar en el flujo de bytes. TCP
funciona solo en modo unidifusión (punto a punto) y lo utilizan aplicaciones como Telnet (emulación de terminal), FTP (protocolo de
transferencia de archivos) y HTTP (servidor web). En una aplicación de automatización industrial, TCP generalmente se usa para
descargar programas de escalera entre una estación de trabajo y un PLC, para software MMI que lee o escribe tablas de datos de
PLC, o para mensajería punto a punto entre dos PLC. UDP es un protocolo de transporte mucho más simple. No tiene conexión y
proporciona una capacidad muy simple para enviar datagramas entre dos dispositivos. No garantiza que los datos vayan a pasar de
un dispositivo a otro, no realiza reintentos y ni siquiera sabe si el dispositivo de destino ha recibido los datos correctamente. Las capas
de aplicación que implementan su propio protocolo de enlace o gestión de conexiones entre dos dispositivos y, por lo tanto, solo
necesitan un servicio de transporte mínimo, usan UDP. Por ejemplo, UDP es utilizado por aplicaciones como SNMP y NFS. UDP es
más pequeño, más simple y más rápido que TCP debido a sus mínimas capacidades y uso de recursos. UDP puede operar en modo
unicast, multicast o broadcast. En una aplicación de automatización industrial, UDP se usa normalmente para funciones de
administración de red, aplicaciones que no requieren una transmisión de datos confiable o aplicaciones que están dispuestas a
implementar su propio esquema de confiabilidad, como la programación de memoria flash de dispositivos de red. Los protocolos y las
aplicaciones que componen el conjunto de protocolos TCP/IP están todos documentados en documentos de solicitud de comentarios
(RFC) que mantiene el Grupo de trabajo de ingeniería de Internet (IETF). El IETF es una organización independiente que actúa como
una organización de estándares para los protocolos de Internet. Los RFC son abiertos y se distribuyen gratuitamente, y se pueden
obtener sin cargo en el sitio web del IETFI.
C. La capa de aplicación y la interoperabilidad El conjunto de protocolos TCP/IP proporciona un conjunto de servicios que dos
dispositivos pueden usar para comunicarse entre sí a través de una LAN Ethernet o de una red de área amplia que se extiende por todo el mundo.
Sin embargo, el uso exclusivo de TCP/IP no garantiza que los dos dispositivos puedan comunicarse de manera efectiva, si es que lo
hacen; solo garantiza que los mensajes de nivel de aplicación se transferirán correctamente entre los dos dispositivos. La comunicación
efectiva entre dos dispositivos requiere que el software de la aplicación sea compatible en ambos lados. Las aplicaciones en ambos
dispositivos deben comprender los atributos y servicios proporcionados por el otro y que utilizan un esquema de mensajería común
para comunicarse sobre TCP/IP (o UDP/IP). Los RFC para aplicaciones populares de Internet como FTP, HTTP, Telnet, SNMP, SMTP
(correo electrónico) documentan completamente cómo deben comportarse esas aplicaciones. Cualquier proveedor que siga esos RFC
debe producir aplicaciones que puedan comunicarse con sus contrapartes en otro dispositivo, incluso si otro proveedor desarrolló ese
dispositivo. La capacidad de los dispositivos de diferentes proveedores para comunicarse a través de la capa de aplicación se denomina
interoperabilidad. Aunque se han establecido servicios comunes para transferencia de archivos (FTP), emulación de terminal (Telnet),
correo electrónico (SMTP) y otros bajo la guía del IETF, la situación no es tan simple en el área de la automatización industrial. Cada
proveedor de equipos de automatización que funciona con Ethernet TCP/IP ha implementado su propio protocolo de capa de aplicación.
Como resultado, los equipos de diferentes proveedores de automatización conectados a la misma intranet de la planta pueden coexistir
físicamente en la LAN pero no pueden interoperar. Los PLC de un proveedor no pueden compartir fácilmente información con los PLC
de otro proveedor a través de una conexión TCP/IP, ni el software de la estación de trabajo del proveedor A puede descargar
información de programación o configuración en el dispositivo del proveedor B. Esta falta de interoperabilidad hace que sea muy difícil
para los clientes integrar equipos de automatización basados en Ethernet de diferentes proveedores dentro de la misma aplicación en
la misma red Ethernet. En consecuencia, podemos ver en la Figura 4 que el protocolo EtherNet/IP puede coexistir con cualquier otro
protocolo que se ejecute sobre las capas de transporte TCP/UDP estándar.
D. Ethernet TCP/IP en la automatización industrial actual Hoy en día, una instalación típica de una red Ethernet TCP/IP puede
extenderse a toda la planta y conectarse a la red mundial de una corporación a través de Internet. Por lo general, se utiliza para
realizar el mantenimiento de programas, enviar datos hacia y desde los sistemas MIS y MES, proporcionar páginas web de intranet,
realizar controles de supervisión, proporcionar conectividad para las interfaces del operador y registrar eventos y alarmas. Estas
funciones requieren el alto rendimiento y la amplia accesibilidad que ofrece Ethernet. El tiempo de respuesta es secundario a la
capacidad general de datos. Algunos clientes actualmente usan Ethernet para fines de control limitado, como compartir datos del
procesador, pero las aplicaciones en las que esto ha tenido éxito aprovechan la alta capacidad de Ethernet, pero no requieren un alto
nivel de determinismo o repetibilidad del tiempo de respuesta del mensaje.
Figura 4: Coexistencia de la capa de aplicación CIP
Machine Translated by Google
Este es un claro ejemplo de la recopilación de datos y servicios de configuración que ofrece EtherNet/IP y que están disponibles a través de Internet.
IV. Intercambio de datos en y entre redes Si bien EtherNet/IP brinda la capacidad de recopilar datos de dispositivos directamente en la red Ethernet
y configurar esos dispositivos en tiempo real, no se puede suponer que una sola red satisfará todas las necesidades. Es posible que los proveedores
individuales no tengan una conexión EtherNet/IP disponible para su dispositivo. Es poco probable que sea rentable en un futuro próximo integrar una
conexión EtherNet/IP completa en dispositivos simples como células fotoeléctricas e interruptores de proximidad inductivos. Esto no significa que se deba
prohibir al usuario hacer uso de EtherNet/IP como punto principal de contacto en la red de destino. Por el contrario, el usuario debería poder trabajar en la
red remota como si estuviera conectado localmente. Además, esto debería ser independiente de cualquier programación de nivel de aplicación o dispositivos
informáticos intermedios. Para lograr esto, las redes en todos los niveles (consulte la Figura 1) deben implementar un conjunto común de servicios y todos los
dispositivos deben organizar sus datos en un modelo de objeto común. Una vez que se ha logrado esta coherencia de datos, se debe definir un mecanismo
para enrutar datos entre redes.
A. Estructuras de datos orientadas a objetos El futuro paradigma de Internet es uno de objetos distribuidos que se comunican de igual a igual dentro
de las intranets corporativas ya través de Internet. Los estándares de "middleware" de la competencia, como DCOM y CORBA, pueden diferir en
la implementación, pero coinciden en el enfoque de objetos distribuidos para la interoperabilidad. La ventaja de una arquitectura de objetos
distribuidos es que permitirá tanto a los desarrolladores de software como a los usuarios finales disfrutar de una interfaz simple, orientada a
objetos y de toda la red para los datos en sus dispositivos de red que parece ser independiente de la ubicación física de los datos. Los detalles
del direccionamiento de la red y las estructuras de datos del dispositivo interno serán transparentes para los usuarios que accederán a los datos
utilizando un esquema de direccionamiento y nombres de objetos que les ocultará dichos detalles. Los paradigmas obsoletos que se basan en
mensajes simples de origen/destino no prosperarán en el futuro entorno de Internet, donde se requerirá que los dispositivos Ethernet de la planta
interactúen con las aplicaciones de información, así como el control de soporte, a menudo en la misma red. Los clientes requerirán que los
dispositivos de diferentes proveedores interoperen en la misma red. Lograr este objetivo requerirá el uso de un protocolo de aplicación que tenga
varias características que son necesidades críticas si se supera la interoperabilidad universal.
Ethernet TCP/IP debe realizarse:
en capas sobre TCP/IP y UDP/IP
implementa un modelo de objetos distribuidos
basado en un estándar industrial abierto
proporciona un modelo eficiente para la mensajería de E/S
permite que el control y la información coexistan en la misma red Ethernet
cumple con los diversos requisitos de la industria de la automatización industrial
es aceptado e implementado por múltiples proveedores de automatización.
B. Biblioteca general de objetos La familia de protocolos CIP contiene una colección bastante grande de objetos comúnmente definidos (actualmente
46 clases de objetos). Solo algunas de estas clases de objetos (1 para DeviceNet, 3 para ControlNet y 2 para EtherNet/IP) son específicas de la
capa de enlace individual; todos los demás son objetos comunes que pueden y serán utilizados en todos
Machine Translated by Google
tres redes. Se agregan más objetos de acuerdo con la funcionalidad del tipo de dispositivo. Esto permite una muy buena escalabilidad de los
dispositivos, por ejemplo, un sensor de proximidad en DeviceNet no se carga con una sobrecarga innecesaria. Un desarrollador generalmente usa
objetos definidos públicamente, pero también puede crear sus propios objetos en el rango de direccionamiento específico del proveedor, por ejemplo,
ID de clase 100 - 199 en el espacio de código de clase de objeto de 8 bits. Sin embargo, se recomienda enfáticamente trabajar en los Grupos de
Interés Especial (SIG) de ODVA y ControlNet International para crear definiciones comunes para otros objetos en lugar de inventar definiciones
privadas. Como ejemplo de un objeto público requerido, los atributos de instancia del objeto de identidad (código de clase: 1) se describen en la
siguiente tabla.
OBJETO DE IDENTIDAD
Atributos opcionales •
Atributos obligatorios • ID
del proveedor • Tipo de
Estado • Valor de consistencia de
dispositivo • Código del
producto • Revisión • Estado
configuración • Intervalo de latido
• Número de serie • Nombre
del producto
Por lo general, los dispositivos no cambian su identidad, por lo que todos los
atributos (a excepción del atributo Heartbeat Interval) son de solo lectura.
C. Hojas de datos electrónicas Tener un modelo de objeto consistente no es útil si
no existe un mecanismo para identificar qué objetos se han implementado en
un dispositivo para aplicaciones externas. CIP ha previsto varias opciones para
configurar dispositivos:
Una hoja de datos impresa
Objetos de parámetros y apéndices de objetos de parámetros
Una hoja de datos electrónica (EDS)
Una combinación de un EDS y Stubs de objeto de parámetro
Un ensamblaje de configuración y cualquiera de los métodos anteriores
Cuando se utiliza la información de configuración recopilada en una hoja de datos impresa, las herramientas de configuración solo pueden
proporcionar indicaciones para el servicio, la instancia de clase y los datos de atributos y transmitir esta información a un dispositivo. Si bien este
procedimiento puede hacer el trabajo, es la solución menos deseable ya que no determina el contexto, el contenido o el formato de los datos. Los
objetos de parámetro, por otro lado, proporcionan una descripción completa de todos los datos configurables de un dispositivo. Esto permite que
una herramienta de configuración obtenga acceso a todos los parámetros y mantenga una interfaz fácil de usar, ya que el propio dispositivo
proporciona toda la información necesaria. Los atributos incluyen el tipo de datos, unidades de ingeniería, valores mínimos, máximos y
predeterminados, factores de escala, si es no volátil, lectura y/o escritura. Sin embargo, este método sobrecarga un dispositivo con información
completa de los parámetros, y esto puede ser demasiado para un dispositivo pequeño, por ejemplo, un esclavo DeviceNet simple. Por lo tanto, se
puede utilizar una versión abreviada del objeto de parámetro, denominada stub de objeto de parámetro. Esto todavía permite el acceso a los datos
de los parámetros, pero no describe ningún significado de estos datos. Aquí es donde un EDS es muy útil. Un EDS proporciona toda la información
que contiene un objeto de parámetro completo además de lo que proporciona el resguardo del objeto de parámetro. La combinación de EDS y stub
de objeto de parámetro proporciona la funcionalidad completa y la facilidad de uso del objeto de parámetro sin sobrecargar los dispositivos
individuales. Finalmente, un ensamblaje de configuración permite la carga y descarga masiva de un bloque completo de parámetros.
D. Protocolo de mensajería Como puede verse en el modelo de objetos que se muestra en la (Figura 5), el acceso al modelo de objetos internos de
cualquier dispositivo está controlado por uno de dos objetos, el administrador de mensajes no conectado y el administrador de conexión. Esto se debe
a que EtherNet/IP es una red basada en conexión. Una conexión CIP define un paquete que se producirá en la red. Cuando se establece una
conexión, a las transmisiones asociadas con esas conexiones se les asigna un ID de conexión (CID). Si la conexión implica un intercambio
bidireccional, se asignan dos valores de ID de conexión. (ver Figura 6). Dado que la mayoría de los mensajes en una red CIP se realizan a través de
conexiones, se ha definido un proceso para establecer dichas conexiones entre dispositivos que no están "conectados".
Machine Translated by Google
aún. Esto se hace a través del Administrador de Mensajes Desconectados (UCMM), que se encarga de procesar las
solicitudes de conexión. Una vez que se ha establecido una conexión, se reservan todos los recursos de comunicación
necesarios en los dispositivos, incluidos los puentes/enrutadores CIP intermedios. Y se minimiza la carga general de la red y
el ancho de banda requerido para ese intercambio de datos.
Figura 5: Modelo de objetos CIP
Todas las conexiones en una red CIP se pueden dividir en conexiones de mensajería explícita y conexiones de
mensajería implícita (o E/S).
Las conexiones de mensajes explícitos proporcionan rutas de comunicación genéricas y multipropósito entre
dos dispositivos. Estas conexiones a menudo se denominan simplemente conexiones de mensajería. Los
mensajes explícitos proporcionan la típica comunicación de red orientada a solicitud/respuesta y siempre se
envían al enrutador de mensajes (Objeto). Cada solicitud contiene información explícita que el nodo receptor
decodifica, actúa y luego genera una respuesta apropiada.
Las conexiones de mensajería implícita proporcionan rutas de comunicación (puertos) dedicadas y de
propósito especial entre un objeto de aplicación productor y uno o más objetos de aplicación consumidores. Este
tipo de mensajería siempre se usa para datos de E/S específicos de la aplicación que se mueven a través de
estos puertos, por lo que la mensajería a menudo se denomina conexiones de E/S. Sin embargo, existen muchas
más aplicaciones para la mensajería implícita. Se denominan mensajes implícitos porque los datos que se van a
intercambiar se identifican en el momento en que se establece la conexión y se asignan los ConnectionID. Cada
transmisión contiene los valores actuales para los objetos de la aplicación que se acordaron cuando se estableció
la conexión. En otras palabras, el ConnectionID define implícitamente el significado de los datos.
Ambos tipos de conexiones se pueden unir entre redes y se analizarán con más detalle más adelante.
E. Conexiones explícitas Como se indicó anteriormente, todas las conexiones explícitas son conexiones directas entre dos
dispositivos, que requieren una dirección de origen, una dirección de destino y un ID de conexión en cada dirección. Los
mensajes explícitos son activados por eventos externos a la capa de aplicación del protocolo CIP. Este es el caso de DeviceNet
y ControlNet, en las que las direcciones de origen y destino son números de nodo en la red, y de EtherNet/IP, donde las
direcciones de origen y destino son direcciones IP. Sin embargo, la trama CIP existe dentro de un paquete TCP y puede incluir
información adicional sobre los nodos de destino: la ruta de comunicación e, igualmente importante, qué 'salto' en esa ruta está
tomando la trama actual. Por lo tanto, tomando la arquitectura de automatización típica en la Figura 1, un mensaje iniciado en la
PC de soporte del dispositivo programable conectado a la red de nivel de información y dirigido al arrancador de motor en la red
de nivel de dispositivo tendrá al menos tres 'saltos'; uno a la red de nivel de información, otro a la red de nivel de control y un
salto final a la red de nivel de dispositivo.
A lo largo de cada uno de estos saltos, la trama CIP permanece intacta durante todo este viaje, mientras existe
consecutivamente en un paquete TCP, un paquete ControlNet y un paquete CAN. El único requisito del arrancador de
motor es asegurarse de que la ruta permanezca intacta en la trama CIP y dirija el mensaje de retorno en un paquete CAN
al número de nodo en la ruta de retorno. Si el nodo de origen está físicamente en la misma red, conectado a una red
EtherNet/IP local o incluso enrutado a una ubicación remota a través de Internet, es transparente para el usuario.
Machine Translated by Google
dispositivo objetivo. Dado que el arrancador de motor en este ejemplo ha sido diseñado de acuerdo con la especificación DeviceNet y el terminal de
programación diseñado de acuerdo con la especificación EtherNet/IP, los 2 dispositivos tienen un entendimiento común de la forma en que se
organizan los datos en el otro. .
Figura 6: Conexiones e ID de conexión
Como se discutió anteriormente, uno de los objetos obligatorios en todos los dispositivos es el objeto de identidad, y los atributos obligatorios de
ese objeto incluyen la identificación del proveedor, el tipo de dispositivo, el código del producto y la revisión. Estos datos se pueden consultar desde
un nodo de destino sin saber físicamente qué dispositivo es antes de que se emita el mensaje. A partir de estos datos, es posible identificar de
manera única el archivo EDS para el dispositivo y, por lo tanto, saber qué objetos públicos se han implementado y, en muchos casos, qué objetos
específicos del proveedor se pueden haber implementado. Para los dispositivos que contienen objetos de parámetros completos, es posible obtener
estos datos directamente desde el dispositivo sin un EDS. Estos mecanismos son independientes de la red de destino, como se puede ver en las
Figuras 2 y 5 , los objetos de datos están aislados de la red de modo que se puede emitir el mismo mensaje para llegar al mismo objeto de datos no
solo independientemente del dispositivo sino también independientemente de la conexión de red. EtherNet/IP, al estar basado en TCP/IP, ofrece un
potencial adicional. En este ejemplo, no hay ningún requisito de que el nodo de origen esté en el nivel de información. Un PLC ubicado en una red de
nivel de control, que está aislado del nivel de información por un PLC o un dispositivo puente (no es importante si la red de nivel de control es EtherNet/
IP o ControlNet) puede originar un mensaje de múltiples saltos que utiliza la información nivel como uno de los pasos intermedios. Esto permite que
dos PLC conectados en ControlNet, en lados opuestos del mundo, se comuniquen mediante mensajes explícitos a través de Internet.
Control V. I/O sobre EtherNet/IP
A. ¿Ethernet como red de control? Uno de los argumentos más comunes que tradicionalmente se ha utilizado contra el uso de Ethernet para el control
es que Ethernet no es determinista. El determinismo permite a los usuarios predecir con precisión la transmisión de datos en el peor de los casos.
Pero los usuarios también necesitan alta repetibilidad (o baja fluctuación); eso es una garantía de su llegada a la misma hora cada vez (o para
reconocer rápidamente que no llegó y tomar las medidas adecuadas). Las mejoras en la tecnología Ethernet que se detallan a continuación han
mejorado en gran medida el determinismo, la repetibilidad y el rendimiento de Ethernet. Los conmutadores dividen los dominios de colisión en
dispositivos individuales o pequeños grupos de dispositivos, lo que reduce efectivamente la cantidad de colisiones a casi cero. CSMA/CD proporciona
el mecanismo para detectar y recuperarse de la contención de la red cuando ocurre. Además, existen esfuerzos para crear un esquema de priorización
de mensajes a través de Ethernet (IEEE 802.1p) que, si se implementa dentro de conmutadores y pilas TCP/IP, podría usarse para priorizar paquetes
de mensajes de control/alarma sobre paquetes de programación/datos o redes de rutina. tráfico de diagnóstico (SNMP). Sin embargo, todas estas son
tecnologías no probadas en aplicaciones de control de alta velocidad. En muchas aplicaciones con tiempos sensibles, un solo mensaje recibido más
tarde de lo previsto puede cerrar el proceso, lo que resulta en pérdida de producción o incluso daños en bienes y equipos. La latencia variable de los
paquetes o los paquetes descartados dentro de los conmutadores Ethernet podrían causar que esto suceda. La pérdida de un concentrador o
conmutador en una aplicación de solo información puede provocar la pérdida de datos de producción; perder uno en una aplicación de control puede
resultar en pérdida de producción y posibles daños al propio equipo de producción. Estos y otros temas deben ser cuidadosamente considerados por
los usuarios para determinar racionalmente los tipos de aplicaciones de control para las cuales la tecnología Ethernet TCP/IP es una solución buena o
incluso aceptable.
B. La evolución de la tecnología de conmutación En los últimos años, tanto la tecnología de concentrador repetidor como la de puente Ethernet
han sido reemplazadas por una nueva tecnología que utiliza técnicas de conmutación de alta velocidad para permitir que el tráfico entre dos puertos
cualquiera del conmutador pase a través del conmutador con una latencia extremadamente baja del orden de microsegundos. Esta tecnología ha
sido habilitada por hardware especializado que puede soportar un backplane de ancho de banda muy alto dentro del dispositivo. La velocidad del
backplane suele ser mayor que la suma de las velocidades de los puertos Ethernet en el dispositivo y puede acomodar todos los puertos funcionando
a toda velocidad sin colisiones.
Además, estos nuevos dispositivos son capaces de almacenar marcos en búfer temporalmente para manejar la contención a corto plazo para el
mismo puerto de salida. Estos nuevos dispositivos se denominan concentradores de conmutación, conmutadores de capa 2 o simplemente
conmutadores. De hecho, un conmutador es un puente multipuerto. Cada puerto de un conmutador es su propio dominio de colisión, por lo que no se
producen colisiones entre los dispositivos conectados al conmutador. Además, cada puerto en un conmutador generalmente se puede configurar para
ejecutarse en medio dúplex (Ethernet tradicional) o en funcionamiento dúplex completo. Full dúplex proporciona una conexión efectiva de 10 Mbit/seg en
Machine Translated by Google
cada dirección (20 Mbit/s en total) entre un dispositivo conectado y el conmutador. Para Fast Ethernet, la velocidad de dúplex
completo es de 100 Mbit/seg en cada dirección (200 Mbit/seg en total). Al igual que los puentes tradicionales, los conmutadores
construyen y mantienen tablas internas que asignan direcciones Ethernet a puertos. Un paquete recibido en un puerto se "conmuta"
rápidamente al puerto de salida apropiado, generalmente en microsegundos. Los conmutadores avanzados admiten una función de LAN
virtual (VLAN) que permite a los usuarios configurar el conmutador para que los puertos se subdividan en grupos, de modo que todos los
paquetes recibidos en un puerto de un grupo solo se transmitirán a otro puerto dentro del grupo. El puerto receptor y el grupo de puertos
transmisores constituyen una VLAN. Por lo general, las VLAN pueden superponerse dentro de un conmutador, de modo que cualquier
puerto puede aparecer en varias VLAN. Esta función permite al usuario una gran flexibilidad para particionar los puertos de un conmutador
en múltiples dominios de colisión superpuestos. Los conmutadores son capaces de manejar un mayor rendimiento que los concentradores
repetidores sin experimentar los retrasos inducidos por colisiones que pueden experimentar los dispositivos en un concentrador repetidor
a medida que aumenta el tráfico de red. Esto los convierte en una buena opción para reemplazar concentradores repetidores en redes
cargadas que experimentan un nivel inaceptable de demoras inducidas por colisiones. Si bien los conmutadores son actualmente más
costosos que los concentradores repetidores, su costo está disminuyendo y pronto será lo suficientemente bajo como para que los
conmutadores reemplacen a los concentradores repetidores como el concentrador de red elegido para todas las redes Ethernet, no solo
las que se utilizan para el control. Es importante tener en cuenta que los conmutadores tienen algunas limitaciones de rendimiento que
pueden afectar a algunas aplicaciones. Si un conmutador experimenta congestión interna debido a paquetes de mensajes en varios
puertos de entrada que compiten por la transmisión en el mismo puerto de salida, es posible que el conmutador simplemente descarte
paquetes. O puede forzar una colisión de regreso a los dispositivos de transmisión, por lo que retroceden el tiempo suficiente para que se
despeje la congestión. El enfoque que se adopte depende de la implementación elegida por el proveedor del conmutador. En cualquier
caso, se inserta una latencia variable en el flujo de mensajes, lo que generalmente no es un problema para las aplicaciones de oficina,
pero puede tener un profundo impacto en las aplicaciones de automatización industrial. Aunque los switches aíslan dominios de colisión
separados en cada puerto, no crean dominios de difusión separados. Sin embargo, cada VLAN es un dominio de difusión independiente,
si esta función está habilitada en el conmutador. Un mensaje de difusión Ethernet que se recibe en cualquier puerto se retransmitirá en
todos los puertos del conmutador a todos los dispositivos conectados. Esto significa que los conmutadores no eliminan el problema del
tráfico de transmisión excesivo que puede causar una degradación severa del rendimiento en toda una red Ethernet cuando se conecta a
la red un dispositivo dañado o configurado incorrectamente. Algunos proveedores de conmutadores están trabajando en métodos
patentados para suprimir el exceso de mensajes de difusión en sus conmutadores, pero esto no es universal. Los mensajes de difusión
son comunes en las redes Ethernet que llevan el protocolo TCP/IP porque TCP/IP utiliza los mensajes de difusión Ethernet para la
resolución de direcciones. Sin embargo, el tráfico de difusión representa un pequeño porcentaje del tráfico de red en una red que está
configurada correctamente y que funciona con normalidad. Además, los conmutadores y concentradores repetidores son dispositivos
activos que contienen circuitos digitales complejos y requieren alimentación (CA en la mayoría de los casos) para funcionar. La falla de un
conmutador o concentrador provocará efectivamente una falla de comunicación para todos los dispositivos conectados a los puertos de
ese dispositivo, incluidos otros concentradores o conmutadores que pueden estar conectados a uno o más puertos del dispositivo
defectuoso. Los dispositivos conectados al concentrador o conmutador defectuoso no podrán comunicarse con el resto de la red de la
planta hasta que se reemplace o repare el conmutador. Además, la mayoría de los componentes de medios Ethernet se han diseñado
para su uso en una oficina o en un entorno industrial ligero. No han sido diseñados ni probados para cumplir con los rigurosos estándares
ambientales típicos de los dispositivos de control industrial (es decir, rango de temperatura ampliado, marca CE industrial, golpes y
vibraciones, etc.). Esto puede convertirse en un problema a medida que la misión de Ethernet en la planta se expande a nuevas áreas.
C. La evolución del rendimiento de Ethernet Los desarrollos más recientes en la tecnología Ethernet incluyen Fast Ethernet y Gigabit
Ethernet. Fast Ethernet se define y documenta en la especificación IEEE 802.3u. Fast Ethernet es básicamente Ethernet funcionando a
100 Mbits/seg. Fast Ethernet y 10 Mbit Ethernet utilizan la misma estructura de trama, esquema de direccionamiento y método de
acceso CSMA/CD. Sin embargo, todos los parámetros de temporización de la red se deben escalar por un factor de 10 al configurar una
red Fast Ethernet. Esto tiende a reducir las distancias entre nodos en algunas configuraciones en comparación con una red de 10 Mbit.
Fast Ethernet proporciona una velocidad de cable que es 10 veces más rápida que la Ethernet tradicional, lo que tiende a beneficiar a las
aplicaciones que consumen mucho ancho de banda, como la transmisión de video y audio, así como la transferencia de grandes archivos
de datos a través de la red. Sin embargo, la mayoría de las aplicaciones no disfrutarán de un aumento sustancial del rendimiento debido
únicamente al aumento de la velocidad del cable. En particular, es probable que una red de planta de pequeños bloques de E/S inteligentes
basados en microprocesadores, sensores, actuadores, unidades y otras interfaces de dispositivos consuman y produzcan pequeñas
cantidades de datos encapsulados en tramas Ethernet de 64 bytes (el tamaño de trama más pequeño admitido). por Ethernet). Es más
probable que el rendimiento de estos dispositivos esté limitado por la velocidad de su microprocesador y el firmware integrado que por la
velocidad del cable. Es poco probable que una red de tales dispositivos utilice completamente el ancho de banda completo de Ethernet
de 10 Mbit/seg, a menos que se haya utilizado un protocolo de capa de aplicación ineficiente que sondeó repetidamente los dispositivos
punto a punto. Un área de rendimiento en la que Ethernet de 100 Mbit puede mostrar una mejora notable con respecto a Ethernet de 10
Mbit es el área de recuperación de colisiones. Como se mencionó anteriormente, los tiempos de retroceso para Ethernet de 100 Mbit son
una décima parte de los de Ethernet de 10 Mbit. En una red cargada donde las colisiones son un problema, Ethernet de 100 Mbit puede
mostrar un rendimiento notablemente mejor que Ethernet de 10 Mbit.
Además, se esperaría que una red Ethernet de 100 Mbit pudiera manejar una carga ofrecida mayor que una red Ethernet de 10 Mbit
antes de que las colisiones se convirtieran en un problema. Si la aplicación requiere el uso de varios conmutadores, los enlaces entre
los conmutadores pueden beneficiarse de la mayor velocidad. Sin embargo, si la carga y las colisiones aún no son un problema en una
red Ethernet de 10 Mbit, la simple actualización a Ethernet de 100 Mbit puede no mostrar una mejora suficiente para justificar la inversión.
D. Mensajería implícita (E/S) a través de EtherNet/IP En la sección 4.5, analizamos la ruta de comunicación y el uso de mensajes
explícitos y mensajes no conectados para intercambiar mensajes punto a punto entre nodos. El segundo tipo de mensajería, la
mensajería implícita, se utiliza cuando el intercambio de datos entre nodos es transparente para el usuario y se lleva a cabo dentro de la
capa de aplicación del protocolo, y tanto los nodos productores como los consumidores conocen el contenido del mensaje antes de la
transmisión. Si bien se usan comúnmente para mensajes de E/S, estos hacen
Machine Translated by Google
uso completo del modelo productor/consumidor y también se usan comúnmente para la comunicación programada
entre controladores. Hay cuatro tipos principales de mensajes implícitos disponibles dentro de la especificación CIP:
encuestados
Cambio de estado
Cíclico
estroboscópico
Los mensajes sondeados tienen en gran medida los mismos atributos que cualquier red de E/S 'anticuada', en la que el
dispositivo escáner (maestro) consulta secuencialmente todos los dispositivos adaptadores (esclavos) enviándoles sus
datos de salida y recibe una respuesta con sus datos de entrada. . Strobed es un caso especial de sondeo en el que el
escáner envía una única solicitud de datos de multidifusión y los esclavos responden secuencialmente con sus datos sin
que se requieran más mensajes del maestro. Los mensajes cíclicos son producidos por un dispositivo en una base
programada predeterminada, con una identificación de conexión asociada con el mensaje. Cualquier otro dispositivo que
requiera los datos del dispositivo productor conoce la ID de conexión y acepta cualquier paquete que vea en la red con esta
ID de conexión. Change of State es similar a Cyclic, excepto que (como su nombre lo indica) los datos se producen en
respuesta a un evento que provocó que los datos cambiaran, en lugar de un evento cronometrado. Change of State también
mantiene una tasa cíclica de fondo (latido) para que las aplicaciones consumidoras puedan saber que el nodo todavía está
en línea y funcionando. De estos 4, Cyclic es el formato de intercambio de mensajes implícitos preferido en una red EtherNet/
IP, que proporciona un equilibrio entre la integridad de los datos y la optimización del tráfico de red. Para la implementación
del protocolo CIP en Ethernet, el aspecto crítico de un mensaje implícito es que puede haber muchos consumidores de un
solo paquete de datos en el cable. Esto hace imposible el uso de paquetes TCP, que son para aplicaciones punto a punto.
Tampoco es deseable inundar la red con paquetes de difusión que no pueden ser rechazados en la capa IP y que
probablemente sobrecarguen los dispositivos terminales. Los paquetes UDP/IP admiten operaciones de multidifusión y tienen
la ventaja adicional de ser la capa de aplicación 'más delgada' y, por lo tanto, requieren la menor cantidad de tiempo de
procesamiento en el dispositivo terminal. Para las aplicaciones típicas, se anticipa que las conexiones se ejecutarán con una
frecuencia de milisegundos de un solo dígito. Los paquetes UDP no se transmiten directamente a la dirección IP "verdadera"
del dispositivo receptor, sino que se transmiten con una dirección de multidifusión IP asignada a un dispositivo específico.
Esta dirección se utiliza en paralelo con (correspondencia uno a uno) el ID de conexión CIP en la implementación de EtherNet/
IP, lo que permite filtrar los paquetes que no son relevantes para un nodo específico antes de su presentación en la capa de
aplicación. El dispositivo consumidor debe conocer esta dirección de multidifusión IP (que ha sido asignada por el productor)
antes de que pueda usar los datos producidos. Para lograr esto, se debe utilizar el Administrador de mensajes no conectados
(consulte la Figura 5).
Figura 7: Conexión implícita de multidifusión
Un paquete punto a punto (TCP) se transmite desde el originador de la conexión (el PLC en una configuración de E/S; el
consumidor en una aplicación de PLC a PLC o equivalente), que indica el objeto de datos que desea el originador de la
conexión. recibir y la velocidad a la que desea recibir los datos. Ahora se interroga al objeto del administrador de conexiones
para identificar si hay una coincidencia en su tabla de conexiones con el objeto de datos y la tasa periódica. Si hay una
coincidencia, entonces el objeto de datos ya se está produciendo (es decir, será de multidifusión) y el ID de conexión y la
dirección IP de multidifusión relacionada se devolverán al posible consumidor (consulte la Figura 7 anterior). Si no hay ninguna
coincidencia, se asignará y cargará una dirección IP relacionada con UDP y un ID de conexión en el objeto del administrador
de conexión. Los datos comenzarán a generarse y pueden ser consumidos por cualquier dispositivo que conozca su dirección
IP de multidifusión y su ID de conexión. La pieza final de esto es que debe haber un mecanismo para cerrar la conexión y ese
mecanismo debe operar cuando el consumidor ya no está conectado a la red.
Como UDP e IP son mecanismos de transmisión no reconocidos, el productor no tiene forma de saber si el consumidor
está en línea y recibe los datos. Para lograr esto, el productor de datos debe invertir el proceso y establecer una conexión
cíclica especial para cada uno de los dispositivos consumidores. No se transmiten datos de la aplicación.
Machine Translated by Google
a través de esta conexión, que se llama "latido del corazón". Si el nodo productor agota el tiempo de espera de todas las
conexiones de latido asociadas con un objeto de datos producido específico, se cierran todas las conexiones asociadas con ese
objeto de datos. En consecuencia, mediante el uso de paquetes TCP para establecer la conexión entre dispositivos y luego
conexiones UDP para canalizar los objetos de datos de E/S, se minimiza la utilización del ancho de banda de la red. Con la llegada
de Ethernet de 100 MBps, esto ya no es tan crítico como lo era antes. Más significativamente, se minimiza el número de paquetes
que cada nodo terminal tiene que procesar y, por lo tanto, se maximiza su capacidad para manejar conexiones implícitas.
VI. Pruebas de conformidad Dado que la interoperabilidad es uno de los principales objetivos de ODVA y ControlNet International al generar
la especificación EtherNet/IP, esas organizaciones han puesto en marcha una serie de instalaciones de prueba de conformidad independientes,
una en Europa, otra en América del Norte y otra en América del Norte. uno en Japón. Se ha establecido un grupo de interés especial conjunto
(JSIG) entre ODVA y ControlNet International para garantizar que se ejecuten procedimientos de prueba consistentes en estos laboratorios. Al
proporcionar estas instalaciones independientes, será práctico para los proveedores de la competencia ofrecer productos sin temor a perder la
propiedad intelectual pero con la confianza de que los productos se integrarán a la perfección. Esto, a su vez,
asegúrese de que los usuarios puedan tomar decisiones basadas en los méritos de los componentes y proveedores individuales en lugar de
sentirse atados a un solo proveedor. El primero de estos laboratorios, en la Universidad de Michigan, EE. UU., se inauguró el 10 de agosto de
2001. Le seguirán unidades similares en la Universidad de Warwick, Reino Unido, y el Instituto de Investigación Mecatrónica y Tecnología de
Software Avanzada (ASTEM RI) en Kioto. , Japón
VIII. Beneficios de EtherNet/IP (Consulte la figura 8). Debido a que ControlNet, DeviceNet y EtherNet/IP utilizan un protocolo de
capa de aplicación común, también comparten una biblioteca de objetos y perfiles de dispositivos. Estos objetos y perfiles permiten la
interoperabilidad plug and play entre dispositivos complejos de múltiples proveedores. Las definiciones de objetos son rigurosas y admiten
diagnósticos, configuración y mensajería de E/S en tiempo real a través de la misma red. Esto significa que los usuarios pueden conectarse
a dispositivos complejos como unidades, controladores de robots, lectores de códigos de barras y básculas sin software personalizado. El
resultado son arranques más rápidos y diagnósticos superiores.
Figura 8: Beneficios de EtherNet/
IP Además, EtherNet/IP proporciona a los usuarios servicios de mensajería explícitos (información) e implícitos (control).
EtherNet/IP, como resultado, proporciona todos los servicios que son esenciales en las redes de control y de nivel de dispositivo, desde
mecanismos de activación por sondeo, cíclicos y de cambio de estado hasta transferencia de datos de punto a punto y de multidifusión.
Finalmente, dada la rápida adopción de ControlNet y DeviceNet, casi 400 proveedores de todo el mundo ya han desarrollado más de 500
productos interoperables para cualquiera de las tres redes. Esto es importante aunque solo sea para ilustrar que el soporte para EtherNet/IP
no tiene paralelo y seguirá creciendo.
VIII. Conclusión Tres avances tecnológicos: el uso de Ethernet de 100 MBps, el uso de conmutadores y la operación full dúplex de los
dispositivos terminales, han reducido tanto la probabilidad de colisiones como las consecuencias de las mismas hasta el punto de hacer que el
control de E/S a través de Ethernet sea un riesgo manejablemente bajo. opción. La aceptación global de Ethernet TCP/IP lo ha convertido en
una opción popular para muchos usuarios finales y para una amplia variedad de aplicaciones de red. Ofrece una gran cantidad de productos
compatibles, alto rendimiento de datos y componentes disponibles comercialmente a costos relativamente bajos. El futuro paradigma de Ethernet
es uno de objetos distribuidos que se comunican de igual a igual, dentro de intranets corporativas ya través de Internet. En este entorno, se
requerirán dispositivos Ethernet de planta para interoperar con aplicaciones de información corporativa, así como para el control de soporte, a
menudo en la misma red. Los clientes requerirán que los dispositivos de diferentes
Machine Translated by Google
los proveedores interoperan en la misma red. Lograr este objetivo requerirá la adopción de una capa de aplicación que:
está en capas en TCP/IP (y UDP/IP)
implementa un modelo de objetos distribuidos
permite que el control y la información coexistan en la misma red Ethernet
proporciona servicios de red de productores/consumidores
cumple con los diversos requisitos de la industria de la automatización industrial
es aceptado e implementado por múltiples proveedores de automatización
Esta es una necesidad crítica en la industria si se quiere lograr el control en tiempo real y la interoperabilidad universal sobre Ethernet TCP/UDP/IP.
IX. Referencias [1] Especificación de DeviceNet, versión 2.0, incluida la errata 4, 1 de abril de 2001, © 1995-2001 de Open DeviceNet Vendor
Association. [2] Especificación de ControlNet, versión 2.0, incluida la errata 2, 31 de diciembre de 1999, © 1998, 1999 por ControlNet International. [3]
Especificación EtherNet/IP, versión 1.0, 5 de junio de 2001, © 2000, 2001 por ControlNet International y Open DeviceNet Vendor Association.
© Instituto de Ingenieros Eléctricos y Electrónicos, EFTA 2001
Publicación ENET-WP001A-EN-P — Octubre de 2001
Reemplaza la Publicación 000-0000-0000 — Mes, Año
Copyright © 2001 Rockwell Automation, Inc. Todos los derechos reservados. Impreso en EE. UU.