DRIVER DE COMUNICACIÓN ETRENET/IP PARA DISPOSITIVOS CONTROLLOGIX

DRIVER DE COMUNICACIÓN ETRENET/IP PARA DISPOSITIVOS CONTROLLOGIX Resumen Alfredo Quintana López 1, Laura Rodríguez García 2 1 Universidad de las Ciencias Informáticas, Cuba, aqlopez@uci.cu 2 Universidad de las Ciencias Informáticas, Cuba, lrguez@uci.cu Los dispositivos ControlLogix son controladores lógicos programables (PLC, por sus siglas en inglés) utilizados en el control de procesos industriales. Estos dispositivos poseen varias interfaces para el intercambio información, una de ellas es: Ethernet. El módulo utilizado por los dispositivos ControlLogix para el intercambio de información en una red Ethernet es el 1756-ENET, dicho módulo utiliza el protocolo de comunicación Ethernet/IP. La empresa venezolana PDVSA cuenta con un sistema de supervisión y control (SCADA) que posee un driver para la comunicación con dispositivos ControlLogix a través del protocolo Ethernet/IP; dicho driver presenta algunas deficiencias. En este trabajo se exponen las experiencias en el desarrollo de un nuevo driver orientado a dar solución a las deficiencias del driver existente. Palabras Clave: ControlLogix, PLC, SCADA, Ethernet/IP, Driver. Introducción La empresa venezolana PDVSA cuenta con un sistema de supervisión y control (SCADA) denominado Guardián del Alba, este sistema posee un driver para la comunicación con dispositivos ControlLogix a través de una red Ethernet utilizando el protocolo de comunicación Ethernet/IP. Dicho driver presenta algunas deficiencias en la comunicación con los dispositivos ControlLogix, ellas son: no soporte para la transferencia de algunos tipos de datos y bajo rendimiento en cuanto a tiempos de actualización de los datos recolectados del dispositivo ControlLogix. Los dispositivos ControlLogix son controladores lógicos programables (PLC, por sus siglas en inglés) que ofrecen un alto rendimiento, presentan un formato modular y permiten la transferencia de datos a altas velocidades. Estas, entre otras características, hacen que los ControlLogix sean muy utilizados en el control de procesos industriales. Los ControlLogix ofrecen varios módulos de comunicación mediante los cuales se puede intercambiar información en redes EtherNet, ControlNet, Data Highway Plus, entre otras. El módulo de comunicación 1756-ENET permite el intercambio de información a través de una red Ethernet utilizando el protocolo de comunicación EtherNet/IP (Ethernet/ Industrial Protocol). EtherNet/IP

EtherNet/IP (Ethernet/ Industrial Protocol) fue introducido en el año 2001 y hoy en día es la más probada, desarrollada y completa solución de red Ethernet industrial disponible para la automatización industrial. EtherNet/IP está basado en los protocolos estándar TCP/IP y utiliza hardware y software Ethernet para establecer un nivel de protocolo para configurar, acceder y controlar dispositivos de automatización industrial (ODVA, 2008a). EtherNet/IP forma parte de una familia de redes que implementan el Common Industrial Protocolo (CIP) en sus capas superiores (ODVA, 2008a) lo que permite una fácil interacción con redes ControlNet y DeviceNet. EtherNet/IP puede encapsular el protocolo CIP, o incluso otros protocolos en tramas Ethernet. El protocolo de encapsulación define el puerto TCP reservado 0xAF12, que debe ser soportado por todos los dispositivos. EtherNet/IP utiliza dos tipos de mensajes: Unconnected messaging (mensajes no conectados): Provee el mecanismo para que un nodo origen pueda enviar un mensaje a otro nodo destino sin haber establecido previamente una conexión CIP (ODVA, 2008b). Este tipo de mensaje es utilizado en el proceso de establecimiento de conexión y para mensajes poco frecuentes y de baja prioridad (ODVA, 2008a). Connected messaging (mensajes conectados): Una conexión CIP es una relación entre dos o más nodos. La conexión establece una tubería virtual entre los nodos para la trasferencia de datos. Reduce el procesamiento de los mensajes dentro de los nodos (ODVA, 2008b). Utiliza los recursos dentro de cada dispositivo, que son dedicados por adelantado para un propósito particular, como por ejemplo el intercambio de información en tiempo real. Estos recursos son reservados y configurados mediante mensajes no conectados (ODVA, 2008a). Common Industrial Protocolo (CIP) Common Industrial Protocolo (CIP) abarca un amplio conjunto de mensajes y servicios para una gran variedad de aplicaciones de automatización. CIP es compatible con cientos de proveedores en todo el mundo y brinda a los usuarios una arquitectura de comunicación unificada. CIP utiliza un enfoque de Modelo de Objetos para el diseño de redes compatibles para los dispositivos. Este enfoque abarca el método de direccionamiento y las normas del intercambio de mensajes para cada uno de los paquetes enviados por la red. También contiene una serie común de servicios para el control, configuración e intercambio de datos que incluyen mensajes implícitos y explícitos. Cada objeto tiene atributos, servicios y comportamientos. (ODVA). Con la utilización de CIP se logra: enrutamiento de paquetes sin costo ni complejidad añadidas. CIP permite originar un mensaje en una red CIP (como EtherNet/IP) y pasarlo a otra red CIP (como ControlNet) sin costo

alguno; permite una coherente integración de control, sincronización, configuración, diagnóstico y seguridad; es independiente del medio, proporcionando la opción de escoger cual red CIP es mejor para cada aplicación. Dispositivos ControlLogix Los dispositivos ControlLogix han evolucionado en gran medida con respecto a sus predecesores. Dentro de los aspectos más importantes de su evolución se encuentra su forma de programación, uno de los avances más importante en ese sentido es el direccionamiento basado en tags. Un tag es un identificador amigable para una porción de memoria, los tags también poseen tipo de dato, que define la organización interna de la memoria y las posibles operaciones sobre el mismo. Los tipos de datos pueden ser: BOOL, BIT ARRAY, SINT, INT, DINT, REAL. Los tags deben tener una longitud inferior a los 40 caracteres y de acuerdo a su alcance se clasifican en tags del controlador (globales) a los cuales se pueden acceder directamente y tags del programa (locales) a los cuales no se puede acceder desde un dispositivo externo. La utilización de tags facilita el trabajo de los programadores debido a que no es necesario trabajar directamente con las direcciones de memoria del dispositivo, minimizando considerablemente los tiempos de desarrollo, implementación, mantenimiento y búsqueda de fallas. Decisiones de Diseño Se utilizará la arquitectura cliente-servidor, en la cual los mensajes no conectados (Unconnected Messaging) serán usados para establecer la conexión entre el driver (cliente) y el dispositivo ControlLogix (servidor), creando una comunicación orientada a la conexión; conexión que se mantendrá activa por mensajes conectados (Connected Messaging), que serán los encargados del intercambio de información entre el driver y el dispositivo. También se utilizarán mensajes no conectados (Unconnected Messaging) para eliminar los datos referentes a la conexión dentro del dispositivo ControlLogix cuando se desee dar por terminada la comunicación. Para una mejor compresión ver (Figura 1).

Figura 1. Flujo de Comunicación. Multi-Service Para el intercambio de información entre el dispositivo ControlLogix y el driver se utilizará el servicio Multi- Service (0x0A) el cual internamente permite agrupar diferentes servicios dentro de un solo mensaje, la cantidad de estos estará dada por la cantidad de bytes que ocupen dentro del mensaje. Con la utilización de este servicio se optimiza la comunicación con el dispositivo ControlLogix, puesto que disminuye la cantidad de mensajes intercambiados así como el procesamiento de los mismos. Maximizar el intercambio de información entre el dispositivo ControlLogix y el driver de comunicación minimizando la cantidad de mensajes enviados por la red, trae consigo el aumento del rendimiento, por lo cual se decide maximizar la cantidad de servicios en un mensaje antes de que este sea enviado al dispositivo. Almacenamiento de mensajes En el driver, el proceso de construcción de mensajes para el intercambio de información con el dispositivo ControlLogix es prácticamente constante (se ejecuta cada vez que se requieran datos del ControlLogix) y necesita para realizarse el uso del procesador (CPU) de la máquina donde se esté ejecutando el driver. Este proceso de construcción de mensajes es invariable a través del tiempo para un mismo grupo de datos. Por ejemplo: La codificación hexadecimal de un mensaje que será enviado a un dispositivo ControlLogix para la lectura de un tag denominado 'ANO' haciendo uso del servicio de lectura Read Tag es [4C 04 91 03 41 4E 4F 00

28 01 01 00]; esta codificación se mantendrá invariable en el trascurso del tiempo. Debido a esto es posible vincular un grupo de datos (tags) con sus respectivos mensajes (de lectura); almacenando estos mensajes se puede disminuir considerablemente el procesamiento dedicado al proceso de construcción de mensajes, puesto que solo se ejecutará el proceso la primera vez que sean requeridos los datos, pues en las próximas peticiones de ese grupo de datos, se reutilizará el mensaje previamente construido y almacenado. Múltiples conexiones Las redes Ethernet utilizan para el control de acceso al medio CSMA/CD -Carrier Sense Multiple Access with Collision Detection- (Acceso múltiple con escucha de portadora y Detección de Colisiones, en español) (IEEE 802.3). Esta característica proporciona el acceso al medio compartido aumentando las prestaciones y evitando las colisiones de los paquetes. Los dispositivos ControlLogix son capaces de manejar múltiples conexiones simultáneamente; el máximo de estas está definido por el modelo del módulo que se utilizará para la comunicación, por ejemplo el módulo 1756-ENBT soporta 128 conexiones (Rockwell Automation) y el 1756-ENET 32 conexiones (Allen Bradley, 1997). Basándose en estos dos aspectos es posible que el driver cree varias conexiones con el dispositivo ControlLogix, y de manera asíncrona se realicen varias peticiones de datos (tags) al dispositivo. Este enfoque permite aumentar la cantidad de información que se puede intercambiar con un dispositivo en un tiempo dado, debido a que se divide la cantidad de peticiones de datos entre las distintas conexiones existentes, posibilitando que se incrementen las prestaciones que brinda el driver. Con esta estrategia se pudiese llegar a la conclusión de que el tiempo de actualización de los datos (tags) disminuye proporcionalmente al aumento de la cantidad de conexiones que establezca el driver con el dispositivo. Esta conclusión no es totalmente correcta, dado que una cantidad elevada de conexiones creadas por el driver para el intercambio de información con el dispositivo puede ocasionar congestión en la red, causando perdidas de información y lentitud en el intercambio de datos. Para evitar estos inconvenientes se debe establecer un máximo de conexiones permitidas por el driver (según las características de cada red) que asegure que la cantidad de conexiones creadas por el driver no causarán congestión en la red ni sobrepasarán la cantidad de conexiones que el dispositivo en cuestión puede manejar. Configuración Para lograr la comunicación con los dispositivos ControlLogix el driver necesita algunos parámetros que permitan establecer los valores específicos de cada dispositivo; como pueden ser: la dirección IP, la ruta hacia el dispositivo, etc. Con el objetivo de establecer y recuperar los parámetros de configuración el driver ofrece varias funciones que permiten la configuración del mismo.

El driver brinda una configuración por defecto que puede ser cambiada antes de comenzar la comunicación con el dispositivo o en tiempo de ejecución. A continuación se listan los principales parámetros de configuración. Parámetro(Tipo de dato) Descripción RPI (Entero) Define la frecuencia que requiere la transmisión de datos. Valor por defecto: 2000 IP (Cadena) Define la dirección IP del dispositivo ControlLogix. Valor por defecto: 127.0.0.1 PlcPath (Cadena) Define la ruta hacia el dispositivo. Valor por defecto: 1,0 SessionError (Entero) ConnectionTimeOut (Entero) ReadTimeOut (Entero) MaxConnection (Entero) Define la cantidad de errores consecutivos para cerrar una sesión. Valor por defecto: 3 Define el tiempo de espera (en mili segundos) para la conexión. Valor por defecto: 1000 Define el tiempo de espera (en mili segundos) para las operaciones de lectura. Valor por defecto: 1000 Define el máximo de conexiones que utilizara el driver para el intercambio de datos con el dispositivo. Valor por defecto: 1 Tabla 1. Parámetros de configuración. Implementación Ethernet/IP permite encapsular el protocolo CIP u otros protocolos, para esto ofrece una cabecera de longitud fija de 24 bytes seguida de una porción opcional de datos. La longitud total del mensaje encapsulado (incluyendo la cabecera) está limitada a 65535 bytes. El primer campo de la cabecera comienza por el comando de encapsulación (ODVA and ControlNet International, 2007), los principales comandos de encapsulación implementados son: Comando RegisterSession: Registra la sesión TCP en el dispositivo. Comando SendRRData: Permite el envío de los datos encapsulados que usan los mensajes explícitos (o no conectados) hacia el dispositivo. Estos mensajes son procesados por el Ruteador presente en todos los dispositivos Ethernet/IP y posteriormente son enviados al objeto correspondiente. Comando SendUnitData: Permite el envío de los datos encapsulados que usan los mensajes conectados hacia el dispositivo. Estos mensajes van dirigidos directamente a las aplicaciones u objetos con las cuales se concretó la conexión CIP. Comando UnRegisterSession: Cierra la sesión TCP abierta anteriormente con el comando RegisterSession.

CIP se encarga de todo el control de los datos del dispositivo; los dispositivos son modelados por CIP como una colección de objetos. Cada clase a la que pertenecen los objetos ofrece servicios y posee atributos y comportamiento. Algunos de los servicios implementados son: Servicio ReadTag: Lee los datos asociados con un tag específico. Servicio WriteTag: Envía un dato para que sea escrito en un tag específico. El tipo de dato debe coincidir con el tipo de dato del tag especificado. Servicio MultipleServicePacket: Solicita varios servicios a la vez empaquetados, estos servicios son ejecutados independientemente en el dispositivo y los resultados de dichos servicios son empaquetados y enviados de vuelta. Segmentos Para lograr el intercambio de información con los dispositivos se hace necesario ensamblar las direcciones (tags) de forma tal que queden codificadas en un formato el cual los dispositivos esperan que les lleguen las direcciones. Con este objetivo se implementaron los segmentos CIP que permiten englobar el esquema de direccionamiento y las rutas para acceder a los dispositivos ControlLogix. Un segmento CIP es el elemento utilizado para hacer referencia, describir y / o configurar una entidad CIP específica (ControlNet International and ODVA, 2001), los principales segmentos implementados son: Port Segment: Utilizado para el ruteo de una sub-red a otra. Logical Segment: Utilizado para definir una dirección particular a un objeto. Network Segment: Usado para especificar parámetros de red que pueden ser requeridos para transmitir un mensaje al dispositivo a través de la red. Symbolic Segment: Contiene un mensaje simbólico en forma de cadena textual. Data Segment: Permite el envío de datos entre las aplicaciones. Tipos de datos Los dispositivos ControlLogix tienen direccionamiento basado en tags. Los tags poseen un tipo de dato determinado, que puede ser: BOOL, BIT ARRAY, SINT, INT, DINT, REAL. El driver desarrollado brinda soporte para el intercambio de todos estos tipos de datos. En una sola petición Multi-Service (0x0A) se pueden combinar los distintos tipos de datos, así como estructuras y arreglos de una, dos y tres dimensiones. Los BIT ARRAY son arreglos de bits, los cuales tienen una longitud múltiplo de 32. Este tipo de dato es trasmitido como valores de 32 bits (DINT). Esto puede traer confusión debido a que en un arreglo analógico por

ejemplo el tag prueba[10] nos devuelve el elemento de la posición número diez del arreglo prueba. En un BIT ARRAY esta operación nos devolverá el DINT de la posición 10 del arreglo y no el bit numero 10 como pudiese asumirse. Para acceder al bit 10 en un BIT ARRAY es necesario obtener el BIT ARRAY de la posición 0 prueba[0] y de ese resultado obtener el bit numero 10. Para una mayor comprensión y sencillez en el proceso de lectura y/o escritura del tipo de dato BIT ARRAY se puede realizar la siguiente operación: Sea el arreglo Array de tipo BIT ARRAY y X el bit deseado del arreglo Array. X / 32 = Y Y * 32 = Z Z X = -(B) El resultado será el bit B del elemento ubicado en Array[Y]. Intercambio de datos Dado que un tag es un nombre descriptivo para una dirección de memoria, en la mayoría de los casos estos están compuestos por varios caracteres; cada caracter ocupa un byte en el mensaje y el mensaje tiene un limite de 500 byte (Allen Bradley, 2000), por lo tanto la cantidad de caracteres por las que están conformados los tags influye de manera decisiva en la cantidad de tags que se puedan incluir en una solicitud. El driver posee la cualidad de poder combinar solicitudes de tipo Multi-Service con solicitudes de tipo lectura de arreglos. En las solicitudes de tipo Multi-Service se envía en cada uno de los servicios el tags correspondiente, por lo que la cantidad de servicios que se puedan incluir en una solicitud de tipo Multi-Service esta muy ligada a la longitud de los tags correspondientes a esa solicitud. A menor longitud de los tags mayor cantidad de datos se podrán obtener en una solicitud Multi-Service. Sin embargo las solicitudes de tipo lectura de arreglos permiten que en una sola petición se puedan leer múltiples elementos de un arreglo con solo enviar el tag asociado al arreglo y la cantidad de elementos que se desean, por lo que se puede aumentar el número de datos a trasferir, la cantidad de elementos que se pueden solicitar en una lectura de arreglo no es ilimitada; se debe solicitar una cantidad de datos que cuya respuesta tenga una longitud menor a 500 bytes (Allen Bradley, 2000). La correcta combinación de Multi-Service con lectura de arreglos contribuye a la mejora de los tiempos de actualización de los datos (tags). El driver brinda la posibilidad de que en un solo mensaje se puedan hacer varias solicitudes de lectura, lo que trae consigo que la respuesta contenga varios resultados, asociados a cada una de las solicitudes. Estos resultados pueden diferir en el contenido y significado de los bits, esto esta dado fundamentalmente por los diferentes tipos

de datos y si la operación contiene algún tipo de error. El driver es capaz de determinar el error en el supuesto caso de que ocurra y si este es asociado al mensaje completo, a algún tag determinado o a varios de ellos. Pruebas Al driver se le realizaron una serie de pruebas las cuales brindaron resultados satisfactorios, algunas de ellas se describen a continuación. Almacenamiento de mensajes vs Construcción de mensajes Se realizaron pruebas de rendimiento para comprobar que el almacenamiento de los mensajes de lectura disminuye el procesamiento (uso del CPU) del driver conllevando a una disminución del tiempo de actualización de los datos (tags). En la Tabla 2 se recogen los siguientes campos: en la primera columna la cantidad de tags a leer; la segunda columna almacenará el tiempo promedio en mili-segundos (ms) de actualización de los tags haciendo uso del almacenamiento de los mensajes y en la tercera se agrupan los valores del tiempo promedio de actualización de los tags haciendo uso del proceso de construcción de los mismos para cada petición. Tags Almacenamiento Construcción 500 1000 1150 3500 5500 6500 8000 10000 14000 Tabla 2. Comparación de almacenamiento vs construcción. Como se puede observar en la tabla, el almacenamiento de los mensajes de lectura asociados a un grupo de datos (tags) contribuye al mejoramiento de las prestaciones del driver; también se puede llegar a la conclusión de que mientras mayor es el número de tags la diferencia entre los tiempos se hace mayor a favor del enfoque de almacenamiento de los mensajes de lectura. Múltiples conexiones Otra de las pruebas realizadas fue la comparación de los tiempos de actualización de los tags entre el driver utilizando una sola conexión con el dispositivo y utilizando varias conexiones, el resultado de la comparación esta en la siguiente tabla. En la Tabla 3 se recogen los siguientes campos: en la primera columna la cantidad de tags a leer; y el resto de las columnas agruparan el tiempo promedio en mili-segundos(ms) de la actualización de los tags haciendo uso de una, dos y tres conexiones respectivamente del driver con el dispositivo ControlLogix. Tags 1 conexión 2 conexiones 3 conexiones

500 1000 1000 1000 3500 5000 5000 3000 8000 10800 8000 4500 Tabla 3. Comparación de varias conexiones. Los datos contenidos en la Tabla 3 muestran una mejora en los tiempos de actualización de los tags en correspondencia al aumento de la cantidad de conexiones. Además de esta relación, se puede apreciar que el aumento de la cantidad de datos (tags) influye de manera decisiva en la mejora de los tiempos de actualización; mientras mayor sea el número de datos a transmitirse mayor provecho se le sacará a la cantidad de conexiones que cree el driver con el dispositivo ControlLogix. Comparación entre versiones Se realizaron pruebas para comparar los tiempos de refrescamiento de los datos (tags) de la versión anterior del driver (1.0) con esta nueva versión (2.0). Las pruebas no se realizaron en un laboratorio de pruebas, sino que se realizaron en una planta donde estaba instalado el sistema. En la Tabla 4 se recogen los datos de las pruebas. En la tabla se recogen los siguientes campos: en la primera columna se encuentran los dispositivos ControlLogix, en la segunda columna se refleja el tiempo promedio (en minutos) de la actualización de los tags utilizando la versión 1.0 del driver y en la tercera columna se agrupan los tiempos de actualización de los tags utilizando la versión 2.0 del driver. Dispositivos Versión 1.0 Versión 2.0 Dispositivo 1 1:30 0:11 Dispositivo 2 0:11 0:02 Dispositivo 3 0:03 0:01 Tabla 4. Comparación entre versiones. Analizando los datos de la Tabla 4 se puede apreciar que los tiempos de actualización de los tags de la versión 2.0 son menores que los de la versión 1.0. Demostrando que se disminuyeron de forma considerable los tiempos de actualización de los datos recolectados. El driver fue probado, integrado e implantado en el SCADA Guardián del Alba con resultados satisfactorios. Hoy en día está siendo utilizado en las instalaciones de PDVSA que utilizan dispositivos ControlLogix. En las instalaciones donde se realizó la implantación se pudo comprobar que los tiempos de actualización de los tags eran similares a los tiempos de actualización de los SCADA propietarios que estaban siendo utilizados hasta ese momento, incluso en viarias instalaciones el comportamiento fue superior a los SCADA propietarios que existían en dichas instalaciones. Con estos resultados se demuestra que el driver que se describe en este documento satisface los requerimientos de un sistema de supervisión industrial.

Todas las pruebas fueron repetidas 3 veces para evitar que condiciones aleatorias afectaran el resultado. Los tiempos reflejados son promedios, calculados a partir de las 3 veces que se realizaron las pruebas. Los tags utilizados en las pruebas fueron de todos los tipos (BOOL, BIT ARRAY, SINT, INT, DINT, REAL), se utilizaron arreglos y estructuras. La longitud promedio de los tags fue 12.5 caracteres. Resultados Se logró la transferencia de todos los tipos de datos. Se logró la disminución del tiempo de actualización de los datos. Se obtuvo un driver de comunicación que posibilita el intercambio de información con dispositivos ControlLogix haciendo uso del protocolo de comunicación EtherNet/IP. Se desarrollaron varias estrategias para aumentar el rendimiento del driver: - Se aprovecharon características internas del protocolo de comunicación EtherNet/IP para aumentar la cantidad de información solicitada al dispositivo en una sola petición. - Se desarrollaron estrategias para disminuir el tiempo de procesamiento de las tramas en el driver. - Se aprovecharon características de las redes Ethernet así como de los dispositivos ControlLogix para hacer varias conexiones concurrentes con los dispositivos y de esta forma disminuir los tiempos de actualización de los datos (tags). Se obtuvo un driver de comunicación desarrollado en C++ haciendo uso íntegramente de herramientas libres; el cual puede ser utilizado en la plataforma libre Linux o en la propietaria Windows. Conclusión Se lograron solventar las deficiencias de la versión anterior del driver. Se demostró que es posible desarrollar un driver para la comunicación con dispositivos ControlLogix utilizando tecnologías libres. Combinando la lectura de arreglos con peticiones Multi-Service se puede elevar el rendimiento en el intercambio de información entre el driver y el dispositivo ControlLogix. La utilización de tags de pequeño tamaño en el ControlLogix contribuye al aumento de la cantidad de datos que pueden ser solicitados en una sola petición al dispositivo (utilizando Multi-Service). De esta manera se disminuye el número de peticiones, incidiendo en el aumento del rendimiento del driver y disminuyendo el uso del medio físico.

El almacenamiento de los mensajes de lectura evita el proceso de construcción constante de los mensajes por parte de driver; elevando de esta manera las prestaciones que ofrece el driver. El driver desarrollado cumple con los estándares del protocolo de comunicación EtherNet/IP y permite la comunicación con dispositivos ControlLogix. Referencias Allen Bradley, 2000. Módulo de interface de comunicación ControlLogix Ethernet 1756-ENET/B. Allen Bradley, 1997. Módulo de interface de comunicación ControlLogix Ethernet 1756-ENET. ControlNet International and Open DeviceNet Vendor Association (ODVA), 2001. CIP Common Specification. IEEE 802.3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specification. Open DeviceNet Vendor Association (ODVA), 2008a. EtherNet/IP - CIP on Ethernet Technology. The CIP Advantage: Technology Overview Series. Open DeviceNet Vendor Association (ODVA), 2008b. EtherNet/IP Quick Start for Vendors Handbook. Open DeviceNet Vendor Association (ODVA) and ControlNet International, 2007. The CIP Networks Library Open DeviceNet Vendor Association (ODVA), www.odva.org. Rockwell Automation, 2012. Logix5000 Data Access, Publicación 756-PM020B-EN-P. Rockwell Automation, 2009. Logix5000 Data Access, Publicación 1756-PM020A-EN-P. Rockwell Automation, 2001.Communicating with RA Products Using EtherNet/IP Explicit Messaging. Rockwell Automation, www.ab.rockwellautomation.com. Vivek Hajarnavis, Richard Piggin, Ray Romito, Viktor Schiffer, 2008. Integration with ControlLogix Programmable Automation Controllers (PACS) using Ethernet/IP.