1. MANEJADOR ETHERNET/IP PARA LOS PLC CONTROLLOGIX EN EL PROYECTO SCADA PDVSA.
Rafael Trujillo Codorníu1, Antonio Cedeño Pozo2, Luis E. García Hernández3, Yasmany Pérez Pérez 4
1 Instituto Superior Minero Metalúrgico, Las Coloradas s/n, Moa, Holguín, rafaeltc@uci.cu
2 Universidad de Ciencias Informáticas, Carr. San Antonio de los Baños, km 2,5. acedeno@estudiantes.uci.cu
3 Universidad de Ciencias Informáticas, Carr. San Antonio de los Baños, km 2,5. legarcia@estudiantes.uci.cu
4 Universidad de Ciencias Informáticas, Carr. San Antonio de los Baños, km 2,5. yyperez@estudiantes.uci.cu
Abstract ⎯ The Allen-Bradley ControlLogix line of programmable logic controllers (PLCs) offers several interfaces: Ethernet, ControlNet, DeviceNet, RS-232 and others. The ControlLogix Ethernet interface module 1756- ENET uses EtherNet/IP, the Industrial Ethernet Protocol. A Open Source Driver for the PDVSA´s Supervisory and Industrial Control System (SCADA) has been developed that utilizes this EtherNet/IP protocol. Features, performance, and design decisions of this driver are presented.
Index Terms ⎯ Ethernet Industrial Protocol, Ethernet/Ip, ControlLogix, SCADA, Driver.
INTRODUCCIÓN
Muchos subsistemas de la empresa petrolera Venezolana PDVSA son controlados con PLCs Allen Bradley de la línea ControlLogix [1]. Para integrar estos PLC al SCADA que se desarrolla en la mencionada empresa era necesario el diseño de un manejador que garantizara el acceso en lectura y escritura a los datos de estos controladores desde el SCADA a través del Protocolo EtherNet / Ip.
EtherNet/IP (Ethernet/Industrial Protocol) [3] es un protocolo de red en niveles para aplicaciones de automatización industrial. Basado en los protocolos estándar TCP/IP, utiliza los ya bastante conocidos hardware y software Ethernet para establecer un nivel de protocolo para configurar, acceder y controlar dispositivos de automatización industrial. Ethernet/IP clasifica los nodos de acuerdo a los tipos de dispositivos preestablecidos, con sus actuaciones específicas. El protocolo de red Ethernet/IP está basado en el Protocolo de Control e Información (Control and Information Protocol - CIP) utilizado en DeviceNet™ y ControlNet™. Basados en esos protocolos, Ethernet/IP ofrece un sistema integrado completo, enterizo, desde la planta industrial hasta la red central de la empresa.
EtherNet/IP permite que los dispositivos de control intercambien información crítica con requerimientos estrictos de tiempo ([6], [7]). Entre los dispositivos que pueden interconectarse con EtherNet/IP se encuentran sensores, actuadores y, en general, dispositivos simples de entrada / salida, dispositivos de alta complejidad tales como robots, controladores lógicos programables y otros. Esta particularidad lo hace muy atractivo para enlazar, bajo un mismo protocolo, todos los eslabones del proceso, desde el SCADA hasta los dispositivos más simples (ver Figura 1).
FIGURA. 1

2. Ethernet/IP es un protocolo de red en niveles, apropiado al ambiente industrial. Es el producto acabado de cuatro organizaciones que aunaron esfuerzos en su desarrollo y divulgación para aplicaciones de automatización industrial: La Open DeviceNet Vendor Association (ODVA), la Industrial Open Ethernet Association (IOANA), la Control Net International (CI) y la Industrial Ethernet Association (IEA). Estas mismas organizaciones se están esforzando para atender a las demandas de conectividad física que el ambiente severo de pie de fábrica exige. Ya se reportan más de 1 millón de nodos instalados en el mundo con este protocolo [8].
EtherNet/IP usa el protocolo CIP (Control and Information Protocol). El CIP es un protocolo que abarca las capas de red, transporte y aplicación del modelo OSI y es compartido también por ControlNet y por DeviceNet, solo que estos últimos utilizan diferentes medios físicos y consecuentemente diferentes capas de enlace. EtherNet/IP hace uso de la tecnología estándar de Ethernet y TCP para transportar los paquetes de comunicación CIP. El resultado es una capa abierta de comunicación por encima de los altamente populares protocolos Ethernet y TCP/IP.
EtherNet/IP proporciona además un modelo productor / consumidor para el intercambio de información de control crítica en el tiempo. El modelo productor / consumidor permite el intercambio de información entre un dispositivo emisor y varios dispositivos receptores (o consumidores) sin la necesidad de que se envíe el mismo bloque de datos varias veces a diferentes destinos. Para EtherNet/IP, esto se logra haciendo uso de la capa de red y de transporte CIP conjuntamente con la tecnología IP “multicast”. De esta manera muchos dispositivos EtherNet/IP pueden recibir la misma información producida por otro dispositivo.
El protocolo de Control e Información (CIP) es un protocolo “peer to peer” orientado a objetos que proporciona conexiones entre dispositivos industriales y dispositivos de alto nivel (controladores). CIP es independiente del medio físico y de la capa de enlace de datos.
CIP define un esquema orientado a conexión para facilitar todas las comunicaciones. Una conexión CIP proporciona un camino entre múltiples “usuarios finales” Los “usuarios finales” de una conexión son aplicaciones que requieren compartir datos. A la transmisión asociada a una conexión en particular se le asigna un identificador cuando se establece la conexión (CID).
EtherNet / IP proporciona un protocolo que puede encapsular el protocolo CIP, o incluso otros protocolos en tramas Ethernet.
El protocolo de encapsulación define un puerto TCP reservado que debe ser soportado por todos los dispositivos EtherNet/IP. Todos los dispositivos EtherNet/IP deben aceptar, como mínimo, dos conexiones TCP en el puerto 0xAF12.
De igual forma el protocolo de encapsulación define un puerto UDP reservado que debe ser soportado por todos los dispositivos EtherNet/IP. Todos los dispositivos EtherNet/IP deben aceptar paquetes UDP por el puerto 0xAF12. Como UDP, a diferencia de TCP, no tiene la posibilidad de reordenar los paquetes, siempre que se usa UDP para enviar mensajes encapsulados, el mensaje completo debe contenerse en un paquete simple de UDP.
Todos los mensajes encapsulados, enviados vía TCP, o vía UDP al puerto 0xAF12, deben estar compuestos por 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.
Tanto la capa de protocolo a que se refiere el presente documento, como el manejador que se expone, usan el llamado protocolo industrial abierto, que es un dialecto de Ethernet / IP creado por Allen Bradley. Este dialecto permite acceder a los valores de las variables a través de nombres simbólicos o “tags” que cumplen determinadas reglas sintácticas y semánticas.
PROTOCOLO INDUSTRIAL ABIERTO
El protocolo industrial abierto es una extensión de CIP realizada por Allen Bradley para acceder a la información de los dispositivos de una manera simple, a través de nombres simbólicos. Esta extensión se encapsula por el mecanismo anteriormente explicado, en paquetes IP. Es compatible con, al menos los siguientes controladores: ControlLogix, PLC2, PLC5, SLC500, Micrologix, FlexLogix y otros.
Los sistemas de control de la familia de controladores programables Logix de Allen Bradley han evolucionado enormemente sobre sus predecesores. Dentro de los aspectos más importantes de su evolución se encuentra su forma de programación. En este sentido, uno de los avances más importante es el direccionamiento basado en nombres o tags.
Tradicionalmente, los controladores eran programados mediante posiciones de memoria. Es decir, cada instrucción estaba asociada a una posición de memoria dentro del mapa de memoria del controlador, la cual podía ser una variable física (una entrada o una salida a campo) o bien una variable interna. Las posiciones de memoria se caracterizaban por tener nomenclatura propia que no podía asociarse a una variable de proceso (por ejemplo MD159 o MW10). Una buena forma de programación obligaba a definir un nombre o "tag" asociado a cada variable de proceso de modo tal que se corresponda con una posición de memoria en el controlador. Teniendo este vínculo, era posible comprender la programación.
Una vez terminada la lógica de control, el software de programación generaba dos archivos. El primero contenía el algoritmo de control propiamente dicho con las instrucciones direccionadas mediante posiciones de memoria (lo llamaremos archivo fuente) y el segundo contenía los nombres de las variables asociadas a cada posición de memoria (lo llamaremos archivo referencial). Ambos

3. archivos eran necesarios para poder visualizar el código de control tal como había sido programado originalmente.
Por otro lado, esta forma de programación obligaba a tener definida la ingeniería de conexionado y cableado antes de empezar a programar. Es decir, se debía conocer exactamente el lugar en los módulos de entradas y salidas donde se conectarían las señales de campo. También era necesario definir si la arquitectura de control sería centralizada o distribuida. Sólo después de tener terminada dicha ingeniería, el programador tendría la información necesaria para comenzar el desarrollo de la lógica de control.
La programación mediante posiciones de memoria fue muy utilizada en el pasado cuando las herramientas de software no estaban muy desarrolladas (muchas de ellas comenzaron trabajando bajo el sistema operativo DOS) y la memoria de los controladores era pequeña, costosa y de baja integración. Los nuevos desarrollos han potenciado las herramientas de programación y los controladores han incrementado significativamente la cantidad de memoria, producto de su reducción de costo y gran capacidad de integración.
En virtud de ello nace la programación basada en “tags”. La misma resuelve todos los problemas antes planteados y potencia la forma de programar como nunca antes.
Los controladores de la familia Logix de Allen Bradley ([2]) no utilizan posiciones de memoria para elaborar su estrategia de control. La programación se hace directamente utilizando el nombre de la variable o “tag”. Es decir, una instrucción se referencia sólo con el tag de la variable asociada a ella. Los tags son nativos al procesador y de ese modo se descargan al mismo, no existiendo la necesidad de que el software compile el programa y lo traduzca a un lenguaje propio del controlador. Así, ya no existen dos archivos generados por el software de programación (uno con el código fuente y otro con los tags) sino que se genera uno solo, el cual se descarga en el controlador Logix directamente. De este modo, al conectarse mediante una PC a un equipo Logix, se adquiere el código de control completo tal como fuera creado (incluyendo los tags correspondientes) sin necesidad de un archivo referencial de respaldo en la PC.
Esta arquitectura es extremadamente flexible y permite a los desarrolladores de sistemas de control diseñar sus sistemas sin estar constreñidos por los requerimientos de organización de la memoria que se encuentran en los PLC clásicos. La naturaleza de los dispositivos permite crear datos dentro del controlador estructurados de acuerdo a las necesidades de la aplicación. A diferencia de los protocolos clásicos (como Modbus) en que el usuario tiene acceso a un conjunto fijo de registros o de bits, la extensión de ControlLogix trata la memoria de manera mucho más dinámica, Su versatilidad permite al usuario seleccionar el nombre de las variables, los tipos de datos, crear estructuras complejas e incluso arreglos, de manera parecida a como los programadores de PC esperan manejar la memoria.
Hay un precio, no obstante, por esta flexibilidad y ese precio es la complejidad de la comunicación. En los PLC clásicos donde los datos se arreglan convenientemente en una lista consecutiva de registros o de bits, la obtención de un gran volumen de datos es simplemente cuestión de especificar el punto de comienzo en la memoria y la longitud del segmento a leer. Con los procesadores ControlLogix, esto deja de ser así, precisamente debido a las amplias posibilidades en la organización interna de la memoria que los mismos presentan. Para lograr tasas adecuadas de recuperación de la información se necesitan diferentes esquemas de optimización, los cuales se expondran en el punto “Decisiones de diseño”.
Estructura de los tags
Para facilitar la comprensión de algunas de las decisiones de diseño exponemos brevemente la conformación de los Tags en el protocolo Industrial Abierto.
Los “tags” son nombres simbólicos por los cuales se accede a la información del PLC. Estos son identificadores con no más de 40 caracteres de longitud. Los tags tienen un alcance. De acuerdo a su alcance se clasifican en tags del controlador (o sea globales) a los cuales se pueden acceder directamente y tags del programa (locales) a los cuales no se puede acceder desde un dispositivo externo. Cada tag tiene un tipo de dato que define la organización interna del dato y las posibles operaciones sobre el mismo. Se soportan tipos atómicos tales como bit, byte, palabras de 16 bits, de 32 bits y tipos estructurados. La siguiente tabla identifica los principales tipos de datos simples predefinidos:
TABLA I
LECTURA DE 200 ARREGLOS DE 200 ENTEROS.
Dato Almacenado
Tipo Correspondiente
Bit
BOOL
Arreglo de Bits
BOOL ARRAY
Entero de 8 bits
SINT
Entero de 16 bits
INT
Entero de 32 bits
DINT
Flotante de 32 bits
REAL
Las estructuras son agrupaciones de diferentes tipos de datos que funcionan como una unidad simple y sirven a un propósito específico. El acceso a un miembro de la estructura se logra utilizando el operador miembro (.). La sintaxis es:
TagEstructurado.miembro
Dependiendo de las necesidades de la aplicación se pueden crear estructuras adicionales.
Los arreglos son secuencias de elementos que tienen el mismo tipo de dato y que pueden accederse a partir de su posición dentro del arreglo. Para diferenciar los elementos de un arreglo se utilizan índices detrás del nombre del

4. arreglo y encerrados por corchetes ([2]). Se pueden crear arreglos unidimensionales, bidimensionales o tridimensionales. El primer elemento de un arreglo siempre es el elemento con índice cero.
Un miembro de una estructura puede ser un arreglo y a su vez un arreglo puede ser un arreglo de un tipo complejo, como una estructura, de manera que los siguientes tags son posibles:
Motor[4].eje.temperatura
Pozo.Muestras[7]
Estos tags deben interpretarse de la siguiente manera; en el primer caso tenemos un tag (Motor) de tipo arreglo unidimensional. El tipo de cada elemento del arreglo es una estructura que tiene un miembro cuyo identificador es eje, que a su vez es de tipo estructura también y tiene un miembro llamado temperatura. Por tanto Motor[4].eje.temperatura se refiere al miembro temperatura de la estructura referida por el miembro eje de la estructura Motor[4].
En el segundo caso el arreglo Muestras es un miembro de la estructura referenciada por el tag Pozo.
DECISIONES DE DISEÑO
Como se mencionó anteriormente en los PLC clásicos (por ejemplo con el protocolo Modbus) donde los datos se arreglan convenientemente en una lista consecutiva de registros o de bits, la obtención de un gran volumen de datos en una transacción simple es relativamente sencilla. Con el protocolo extendido Ethernet IP de ControlLogix, esto deja de ser así, precisamente debido a las amplias posibilidades en la organización interna de la memoria que los mismos presentan. Para lograr tasas adecuadas de recuperación de la información se necesitan diferentes esquemas de optimización, que se exponen a continuación:
Conexiones persistentes
En todas de las bibliotecas de código abierto consultadas (ver, por ejemplo, [4] y [5]), se usa el esquema de establecer totalmente la conexión al dispositivo en cada operación de lectura y liberar la conexión al finalizar la operación. Este comportamiento presenta varias ventajas, entre ellas; mantiene menos recursos del dispositivo ocupados, la lógica de programación es más simple puesto que no requiere el envío de latidos periódicos para mantener la conexión activa y tiene un rendimiento aceptable para aplicaciones pequeñas.
Con el objeto de comprobar cual era la penalidad de abrir y cerrar las conexiones en cada operación se efectuaron varias pruebas con un PLC Prosoft de Allen Bradley , dos de las cuales se muestran en las Tablas 2 y 3.
En la primera prueba, cuyos resultados se muestran en la Tabla 2, se leyó del dispositivo un arreglo de 200 enteros de manera consecutiva (200 veces) y se midió el tiempo empleado en toda la transacción, usando el esquema de conexiones persistentes (es decir sin abrir y cerrar las conexiones en cada operación) y usando el esquema de conexiones volátiles. La prueba se repitió 3 veces para evitar que condiciones aleatorias en la red usada afectara los resultados.
En la segunda prueba, cuyos resultados se muestran en la Tabla 3, se compararon las lecturas de arreglos de 400 BOOL.
Los resultados arrojan una diferencia estable y significativa entre ambos esquemas del orden de 4 a 1, lo cual indica que la apertura y cierre de la conexión TCP y la creación y destrucción del objeto CIP conexión, en el PLC, es una operación costosa y que si bien el esquema de conexiones volátiles es admisible para pequeñas aplicaciones (admite mas de 40 peticiones de lectura por segundo) , para la operación de un SCADA es inadmisible.
TABLA 2
LECTURA DE 200 ARREGLOS DE 200 ENTEROS.
Modelo
Repetición
Tiempo (ms)
CON CONEXIÓN PERSISTENTE
I
II
III
2227
2316
2198
SIN CONEXIÓN PERSISTENTE
I
II
III
9014
8780
8823
TABLA 3
LECTURA DE 200 ARREGLOS DE 400 BOOL.
Modelo
Repetición
Tiempo (ms)
CON CONEXIÓN PERSISTENTE
I
II
III
2218
2187
2245
SIN CONEXIÓN PERSISTENTE
I
II
III
8659
8713
8801
Lectura de arreglos. Densidad de los paquetes
Una de las maneras clásicas de optimizar las lecturas es tratar de recuperar la mayor cantidad de valores en una transacción simple. En virtud de que mediante el protocolo podemos obtener los elementos de un arreglo (siempre y cuando el tamaño total del mensaje no exceda 488 bytes) si necesitáramos leer en un instante de tiempo los tags Temp[1] y Temp[9] podríamos optar por hacerlo en una transacción leyendo los 9 elementos del arreglo a partir de Temp[1]. Por supuesto que en este caso estamos forzando al PLC a entregarnos información no útil (los valores Temp[2], Temp[3], ..., Temp[8] ), lo cual también tiene un costo. El concepto de densidad de un paquete o bloque de registros refleja la proporción de datos útiles, con respecto al total, en

5. el paquete solicitado. Una densidad muy baja en los paquetes podría tener un impacto negativo en el rendimiento al incrementar innecesariamente la cantidad de datos a transferir y ocupar el CPU del PLC en transferencias innecesarias. Por otra parte obligar el uso de densidades muy altas puede provocar fragmentación en las solicitudes lo que también puede disminuir el rendimiento.
Para poder decidir cual es la densidad óptima en el protocolo se decidieron efectuar pruebas que permitieran definir el costo de la lectura de un arreglo con respecto al costo de un elemento simple.
Los resultados de las pruebas se muestran en las Tablas 4 y 5. En el primer caso se compara la lectura de un tag entero con respecto a un arreglo de 200 enteros. La operación se repite 200 veces y se mide el tiempo total resultante. La prueba se repite 3 veces para eliminar la influencia de factores aleatorios que puedan afectar la misma.
TABLA 4
LECTURA DE 200 TAGS
Modelo
Repetición
Tiempo (ms)
TAG SIMPLE ENTERO
I
II
III
2127
2116
2158
TAG ARREGLO DE 200 ENTEROS
I
II
III
2216
2325
2188
De igual modo se valoró la lectura de un arreglo de 400 BOOL con respecto a un tag simple de tipo BOOL.
TABLA 5
LECTURA DE 200 TAGS
Modelo
Repetición
Tiempo (ms)
TAG SIMPLE BOOL
I
II
III
2172
2164
2198
TAG ARREGLO DE 400 BOOL
I
II
III
2239
2178
2254
Como se aprecia en los resultados no existen diferencias estadísticamente significativas entre la lectura de tags simples y de arreglos. Por tanto se tomó la decisión, para el manejador, de no exigir una densidad mínima en los paquetes. Si se necesitan, en un instante dado, dos elementos de un arreglo con índices i y j el manejador procederá a leer el segmento completo desde i hasta j, siempre y cuando el segmento en cuestión no ocupe un número de bytes que exceda el máximo admitido por el protocolo (generalmente 488 bytes). Si la “distancia” entre los dos elementos provoca un segmento de longitud mayor a 488 bytes se procede a fragmentar la solicitud de lectura en 2 solicitudes.
La implementación del mecanismo de optimización se basa en la asociación, a cada tag, de un nuevo tag que denominamos tag Base. El tag Base de una variable es un tag que se obtiene del tag de la variable de acuerdo a las siguientes reglas:
• Si el tag termina con una referencia a un miembro de una estructura o es un tag simple el tag Base coincide simplemente con el tag.
• Si el tag de la variable termina en una referencia a un elemento de un arreglo, el tagBase se obtiene sustituyendo el último índice del arreglo por el valor cero.
Las variables que tengan el mismo tag Base se diferenciarán entre si, obviamente, por el último índice en la referencia al arreglo. Al ser elementos de un mismo arreglo tienen un mismo tipo de dato simple . Supongamos que las variables que comparten un mismo tag Base dTT son y sean los índices correspondientes. Sea el mayor de los índices e el menor de ellos. Entonces las variables serán asignadas a un mismo bloque de encuesta para lectura y recuperadas en un solo mensaje si y sólo si el producto de la diferencia nvvv,,,21Kniii,,,21Kmaximininvvv,,,21K)(minmaxii− por la cantidad de bytes que ocupa el tipo de dato es menor que 488. Adicionalmente si la operación es de escritura se exige que los índices de las variables sean consecutivos (ver el punto “Escritura de arreglos”), a excepción de los arreglos de bits, en que se admiten salidas de datos no consecutivos. dT
En la tabla siguiente se muestran algunos ejemplos de tags y sus correspondientes tag Base.
TABLA 6
RELACIÓN ENTRE LOS TAGS Y LOS TAGS BASE
Tags
Tag Base
Temp1
Temp1
Temp1.value
Temp1.value
Temp1[3]
Temp1[0]
Temp1[3].Value
Temp1[3].Value
Temp1[3].Data[4]
Temp1[3].Data[0]
Temp1[3].Data[5,2]
Temp1[3].Data[5,0]
De igual manera se evaluó el costo de escrituras de tags simples con respecto a escrituras de arreglos. Las pruebas son similares a las expuestas anteriormente y se muestran en la Tabla 7.
TABLA 7
ESCRITURA DE 200 TAGS
Modelo
Repetición
Tiempo (ms)
TAG SIMPLE ENTERO
I
II
III
2571
2463
2499
TAG ARREGLO DE 200 ENTEROS
I
II
III
2639
2558
2584

6. Como se aprecia no hay diferencias estadísticamente significativas entre los tiempos de respuesta a solicitudes de escritura simple o escritura múltiple.
Escritura de arreglos
Como se concluyó en al punto anterior, la estrategia que se implementó en el manejador EtherNet/IP es la de combinar las solicitudes de lectura de elementos de un arreglo en una transferencia única desde el menor índice solicitado hasta el mayor. Esta estrategia lleva a una reducción significativa de los tiempos de transferencia pero su aplicación en la operación de escritura puede tener efectos colaterales: la escritura de paquetes cuya densidad no sea cero modifica valores de variables que pueden haber cambiado desde el último acceso que se hizo a las mismas y cuya alteración era innecesaria. Por ejemplo supongamos que se desean modificar las variables Temp[1] y Temp[3]. Supongamos que, extrapolando la estrategia usada en la lectura, se decide realizar la escritura en un solo bloque, desde la variable Temp[1] hasta Temp[3]. Esto compromete a modificar de manera correcta Temp[2]. Para ello, una variante posible es depositar el último valor conocido. Pero esto puede ser incorrecto si se considera que ese valor pudo haber sido modificado por otras fuentes (por ejemplo un HMI) sin que el cambio fuera conocido por el SCADA. Es por ello que la estrategia usada para las escrituras es exigir que la densidad de los paquetes sea de 100%. Esto quiere decir que los paquetes de escritura serán fragmentados hasta que cada fragmento quede sin “salidas falsas”.
Una excepción a esta regla la constituyen los llamados arreglos de bits. Las variables booleanas en ControlLogix pueden organizarse en arreglos de bits, en cuyo caso en un entero de 32 bits del PLC se almacenan 32 valores BOOL. Si BoolEx es una arreglo de bits, el intento de leer exclusivamente BoolEx[2], falla, es necesario leer toda la palabra en que ese elemento está contenido, o sea hay que leer obligatoriamente un entero de 32 bits a partir de BoolEx[0] y luego determinar el valor de BoolEx[2] haciendo un AND lógico con la máscara correspondiente.
En escritura el procedimiento es análogo. No existe manera de cambiar el valor de BoolEx[2] sin modificar los valores de los restantes bits. La opción de enviar los últimos valores conocidos en los restantes bits puede provocar efectos colaterales como los mencionados anteriormente. Por ello, en este caso específico, la estrategia que usa el manejador consiste en efectuar una lectura previa del arreglo de bits, modificar los valores necesarios y luego escribir el bloque completo. Observe que esta estrategia no elimina el problema del efecto colateral, ya que mientras se lee el arreglo de bits y se manipula, otro dispositivo puede modificar uno de esos bits sin que el SCADA se entere de esos cambios y dar por tanto una ”salida falsa” . Sin embargo la probabilidad de que esto ocurra es mucho más pequeña y es prácticamente la única estrategia posible.
Podemos ilustrar el esquema que usa el manejador Ethernet / IP para la escritura de arreglos de bits con el siguiente ejemplo: Supongamos se necesita modificar los valores BoolEx[40], BoolEx[70] y BoolEx[90]. El manejador lee el bloque de enteros de 32 bits más pequeño que contiene esos 3 bits. En el caso mencionado sería el bloque de bits desde el bit 32 hasta el 96. Luego el manejador modifica los tres bits necesarios y efectúa una operación de salida.
Arreglos multidimensionales y estructuras
En la versión actual del manejador no es posible obtener información sobre las dimensiones de los tipos estructurados o sobre los límites de los arreglos. Esto compromete la estrategia de optimización. Por ejemplo supongamos que tenemos un arreglo bidimensional AuxData que contiene una matriz de 3x3 valores enteros. El PLC organiza internamente los valores por filas, es decir en el orden:
[0,0]; [0,1]; [0,2]; [1,0]; [1,1]; [1,2]; [2,0]; [2,1]; [2,2]
Supongamos además que, en un instante dado, se desean leer los valores A[0, 1] y A[1, 0]. Observe que la “distancia” entre ambos elementos es de solo 2 elementos y por tanto es posible leer ambos valores en una transacción única ordenando leer 3 valores del arreglo a partir de AuxData[0, 1]. Sin embargo para hacer eso el manejador debe “conocer” que el rango de variación del primer subíndice es de 0 a 2. Sin esta información es imposible calcular la distancia entre los dos elementos del arreglo. Como la versión actual del manejador no obtiene la información de tipo de los tipos complejos la optimización en este caso es imposible y el sistema decide fragmentar la solicitud en dos solicitudes, una para el elemento AuxData[0, 1] y otra para el elemento AuxData[1, 0]. Observe, sin embargo, que si los elementos a leer, fueran AuxData[0,0] y AuxData[0,2], el sistema reconoce adecuadamente que es posible obtenerlos en una sola transacción ya que no necesita conocer el rango de variación del primer índice para calcular la distancia.
De esta manera, una regla práctica que puede incrementar el rendimiento del manejador es agrupar las variables que se leen con un período similar en arreglos unidimensionales y disminuir el uso de arreglos multidimensionales.
IMPLEMENTACIÓN DEL PROTOCOLO.
La biblioteca del Protocolo EtherNet/IP se desarrolló en dos capas fundamentales; una capa se encarga de implementar el protocolo de encapsulación Ethernet. La otra implementa la capa CIP que es encapsulada en paquetes Ethernet. . Los principales comandos que ofrece la capa de encapsulación Ethernet implementada son:

7. • Comando RegisterSession. Se encarga de registrar 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 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.
Encima de esta capa de encapsulación se encuentra la capa de control CIP que 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 comunes implementados son:
• Servicio GetAttributesAll. Retorna el contenido de todos los atributos de una clase CIP u objeto.
• Servicio SetAttributesAll. Modifica los valores de todos los atributos de una clase CIP u objeto.
• Servicio GetAttributeSingle. Retorna el contenido de un atributo específico de un objeto CIP.
• Servicio SetAttributeSingle. Modifica el contenido de un atributo especifico de un objeto CIP.
• Servicio MultipleServicePacket. Solicita varios servicios a la vez empaquetados, estos servicios son ejecutados independientemente en el dispositivo y los resultados de dichos servicios son enviados de vuelta empaquetados previamente.
La capa CIP permite la comunicación entre el SCADA y la(s) aplicación(es) productora(s) en el dispositivo usando mensajes conectados, así como la comunicación usando mensajes explícitos o “desconectados”. Para que la comunicación del SCADA con un dispositivo se lleve a cabo el protocolo debe ser capaz de generar las direcciones de las variables de forma que el dispositivo las entienda correctamente. Para esto se implementaron todos los segmentos de una dirección, permitiendo así cubrir el esquema de direccionamiento presente en las extensiones del protocolo CIP basado en tags.
Los segmentos que pueden componer una dirección y están implementados en el protocolo son:
• Port Segment. Indica el puerto por el que se accedera al dispositivo.
• 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. Este es el segmento que permite el envío de datos entre las aplicaciones.
Conjuntamente con los servicios comunes esta implementación del protocolo cuenta además con los servicios de la extensión Logix para dispositivos Ethernet/IP.
PARÁMETROS DE CONFIGURACIÓN.
La interfaz genérica de comunicación con los dispositivos del proyecto SCADA PDVSA [9] permite la configuración “en caliente” de los manejadores y de los dispositivos. Para ello ofrece funciones que permiten recuperar y establecer los parámetros de configuración de los mismos.
En la siguiente tabla se muestran los parámetros de configuración más importantes de los dispositivos Ethernet/Ip así como sus valores por defecto.
TABLA 8
PARÁMETROS DE CONFIGURACIÓN DEL DISPOSITIVO
Nombre del Parámetro
Descripción
PlcPath
Permite especificar donde se encuentra el dispositivo con el cual se hará la conexión. El formato de la cadena es el siguiente: IP (dirección IP del PLC), Slot y Backplane.
Valor por defecto: "192.168.11.155,1,0"
IpConnectionTimeOut
Establece la cantidad de milisegundos que se esperará para establecer la conexión en cada intento. Una vez vencido este tiempo sin lograr la conexión se reportará un error.
Valor por defecto: 1000
IpReceiveTimeOut
Establece la cantidad de milisegundos por los que se esperará una respuesta del dispositivo antes de abortar la espera y declarar la transacción fallida.
Valor por defecto: 1000
RetriesCount
Define la cantidad de veces en que una transacción se intentará repetir en caso de falla.
Valor por defecto: 3
PlcType
Define el tipo de interfaz con que se efectuará el acceso. Es un tipo enumerado con la siguiente declaración:
enum PlcType
{
PLC5,
SLC500,
LGX
};
Valor por defecto: LGX
CONCLUSIONES
El manejador implementado para el SCADA PDVSA ofrece un mecanismo configurable y adaptable para la comunicación del SCADA con dispositivos EtherNet/Ip que soporten el Protocolo Industrial Abierto. Con las optimizaciones realizadas es posible captar hasta 16,000 tags analógicos por segundo y hasta 34,000 tags boleanos por segundo de acuerdo a las pruebas realizadas. Esto satisface

8. plenamente los requerimientos de un sistema de supervisión industrial.
El desarrollo de futuras versiones de este manejador debe incluir:
• Navegar por los dispositivos asociados al manejador usando la capacidad del protocolo EtherNet/Ip de “rastrear” las identidades de los dispositivos conectados a la red.
• Navegar por el espacio de variables de cada dispositivo.
• Recuperar información de tipo de los arreglos multidimensionales y de los tags estructurados en general, con el objetivo de refinar los mecanismos de optimización abordados en “Decisiones de Diseño”
.
AGRADECIMIENTOS
Este trabajo ha sido patrocinado de manera directa o indirecta por:
• Petróleos de Venezuela S.A. (PDVSA)
• Universidad de Ciencias Informáticas (UCI).
• Grupo de Desarrollo “EROS”, SerCoNi.
Los autores expresan su agradecimiento a todas las personas de las instituciones mencionadas que han posibilitado la realización de este trabajo.
REFERENCIAS
[1] Rockwell Automation,, “ControlLogix Selection Guide”, Publication 1756-SG001A-US-P from http://www.ab.com, July 2000.
[2] Rockwell Automation, “Logix5000 Data Access”, Pub.1756- RM005A-EN-E from http://www.ab.com, March 2000.
[3] Open DeviceNet Vendor Assoc., “EtherNet/IP Specification, Preliminary Release 8”, http://www.odva.org, March 2001.
[4] Stéphane Jeanne, “Ethernet/IP Library for Linux (TuxEip)”, 2006, from http://s.jeanne@tuxplc.net
[5] Gage Ron “CELL Programmers Guide”, Jun. 2001 from http://freshmeat.net/projects/cell/
[6] Skeie, T. Johannessen, S. Holmeide, O., “Timeliness of real-time IP communication in switched industrial Ethernet networks”, IEEE Transactions on Industrial Informatics, ISSN: 1551-3203, Volume 2, Feb. 2006
[7] Oka Minoru, Suganuma Hiromu, “Ethernet-Based Open Industrial Protocol-Its Implementation and Evaluation”, Omron Tech, ISSN:0474-1315, Volume.42;No.2, 2002.
[8] Davies, S, “Industrial ethernet - The fundamentals of ethernet/IP”, : Computing & Control Engineering Journal, ISSN: 0956-3385, Volume 18, Feb.-March 2007.
[9] Trujillo Rafael, “Especificación de la interfaz genérica con el SCADA”, versión 4.1, Entregable según Anexo 13 del convenio Marco PDVSA ALBET, Nov. 2007
[10] Christopher Kohlhoff, “Networking Library Proposal for TR2”, Sept. 2006, from http://asio.sourceforge.net