En cada continente o región, impera un bus de campo diferente, lo que dificulta la automatización de la maquinaria

Un configurador de buses de campo “universal”

René Heijma, Product Engineer en Omron Europe B.V., ‘s Hertogenbosch/Países Bajos.
01/11/2005

Los fabricantes de maquinaria a nivel global se enfrentan a un dilema. En cada continente o región, impera un bus de campo diferente, por lo que la solución de automatización de sus máquinas tiene que ser diferente para adaptarse a las necesidades de los usuarios finales.

Esto supone un problema para los fabricantes de maquinaria, ya que necesitan desarrollar diferentes configuraciones de máquina para cada bus de campo. O lo que es aún peor, el uso de una herramienta de configuración de software para cada dispositivo. Aunque les gustaría utilizar una única herramienta, lo cierto es que tienen muchas.

Omron es un proveedor global de equipos de automatización industrial. Trabajar globalmente significa que debe soportar más de un bus de campo en cada continente. ¿Significa esto que necesita un configurador diferente para cada bus de campo? La respuesta es no. La razón es obvia. Un sólo configurador permite a Omron y a sus clientes, reducir costes de desarrollo, costes de mantenimiento, menos formación de usuarios, menos soporte, etc ...

Diferentes redes, diferentes productos, diferentes proveedores. El objetivo es reducir el número de herramientas de software a uno. ¿Cómo puede conseguirse? Profibus, por ejemplo, define tres formas de configuración. Vía ficheros GSD, EDDL y FDT/DTM.

¿Significa esto que necesita un configurador diferente para cada bus de campo? La respuesta es no. Un sólo configurador permite reducir costes de desarrollo, de mantenimiento, menos formación de usuarios, menos soporte, etc ...

A Omron le gustaría integrar DeviceNet y Ethernet/IP, basados en CIP (Common Industrial Protocol), configurables mediante archivos EDS, en un único configurador de bus campo.

Pero ¿por qué conformarse con sólo estos dos tipos de bus de campo? ¿Por qué no intentarlo con otros dispositivos y sus diferentes herramientas de software de configuración?

En algunos casos, se da la situación en la que los dispositivos están contectados a un bus de campo, controlado por un maestro de otra marca. En este caso, Omron debería disponer de una herramienta de configuración para sus equipos que permita al usuario la posibilidad de configuralos correctamente con la ayuda de dicha herramienta.

Debido a que cada día los equipos son más complejos, se necesita de un sistema intuitivo, con una interface de usuario sencilla (GUI), para su correcta configuración. Entre estos equipos se encuentran controladores de temperatura, sensores de nivel, sensores láser, convertidores de frecuencia y servomotores, y dispositivos de E/S. En efecto, se puede pensar que todos estos equipos tienen muchos parámetros y que se necesita un potente interfaz de usuario para su configuración. Incluso un simple convertidor puede tener más de 100 parámetros.

¿Cómo soportar múltiples redes de bus de campo desde un único configurador?

Ante esta situación, Omron empezó a buscar una herramienta de configuración específica. Después de evaluar la especificación FDT/DTM (Field Device Tool/Device Tool Management), la compañía llegó a la conclusión de que respondía a estas necesidades. Describe perfectamente la separación entre funciones dependientes del bus de campo, y las partes comunes. La parte dependiente del bus de campo se describe en un anexo que tiene que ser añadido por bus de campo. También, si fuera necesario, sería fácil añadir una red propia simplemente utilizando esquemas de comunicación XML.

¿En qué consiste el esquema de comunicación anexo?

El esquema de comunicación XML describe los datos que se mueven entre un dispositivo DTM y un Maestro, o DTM de Comunicación. Hay que distinguir varios tipos de datos. El primero es cuando un equipo DTM quiere comunicar con un equipo de campo para enviar, o configurar, los parámetros. Esto es lo que llamamos comunicación, o configuración on line. Un maestro o un DTM de comunicación no hace más que transmitir datos y puede añadir información en ruta.

Otro tipo de datos incluye la configuración que un maestro necesita para comunicar con un dispositivo de campo, como por ejemplo, el tamaño de las Entradas/Salidas, el tipo de unidades y la marca. Otro tipo de dato es la información de configuración que el maestro debe pasar al equipo de campo antes de que se establezca la comunicación. Esto es básicamente lo que hace Profibus. Este dato es normalmente almacenado en el maestro para poder conectar y comunicar con el dispositivo de campo.

La última posibilidad es que otro DTM pregunte al dispositivo DTM qué parámetros están disponibles o accesibles. Esto es necesario para monitorizar el dispositivo, por ejemplo. Primero se recupera un listado de parámetros y, entonces, se utiliza una comunicación DTM para recuperar todos los datos o partes específicas de datos desde el dispositivo de campo. Esta sería una aplicación típica de HMI.

¿Difiere mucho una red de bus de campo para configurar un maestro de otra para configurar un equipo de campo?

Realmente, no hay muchas diferencias. Todos necesitan, de una manera o de otra, la misma información. El maestro debe obtener información sobre los esclavos, como puede ser la configuración y el tamaño de E/S, y debe haber una manera de llegar al dispositivo de campo directamente para configurarlo y monitorizarlo.

Partes comunes y específicas del bus de campo

Como he mencionado antes, la especificación FDT distingue entre el bus de campo y las partes comunes de un configurador. Cuando un dispositivo de campo dispone de diferentes interfaces de campo, las partes comunes deben ser las mismas. El tipo de interfaz de usuario y los parámetros configurados no debe afectar a los diferentes interfaces de bus de campo. El interfaz de usuario no tiene que mostrar el campo utilizado.

La lógica dice que un interfaz de usuario no tiene que depender de otro interfaz de bus de campo. Solo el traslado de parámetros mediante el software configurador al dispositivo de campo dependerá del bus de campo. Así que la principal parte del software no tiene que cambiar cuando se implementa un bus de campo diferente. Esto es de gran importancia para las empresas que desarrollan el software de configuración, y para los usuarios que están familiarizados con el interface de usuario concreto. El usuario no tiene porqué conocer el interfaz de bus de campo utilizado.

La principal parte del software no tiene que cambiar cuando se implementa un bus de campo diferente

Un gran detalle. Busquemos un ejemplo de cómo funciona el traslado de parámetros a través del interface de usuario del software de configuración al dispositivo de campo.

El dispositivo de bus de campo en nuestro ejemplo se presenta en dos versiones; una en DeviceNet, y otro en Profibus DP-V1. Ampos interfaces de bus de campo permiten el traslado de parámetros online. En DeviceNet la manera de hacerlo es mediante desarrollo de un servicio (SetAtributSingle) en un atributo de una instancia determinada.

Desde una única herramienta Omron soportará diferentes buses de campo, ya sea Profibus o Device Net o cualquier otra clase de bus de campo, interpretando archivos DTMs de texto o DTMs reales. Los ingenieros de las máquinas o de las fábricas no encontrarán demasiadas diferencias entre ellos.

Profibus DP-V1 lo hace de manera similar, pero en este caso se llama Write Command que se encuentra en un índice en una posición dentro del dispositivo del bus de campo. El envío desde el software de configuración, del parámetro configurado en el interfaz de usuario al dispositivo de campo, a través del bus de campo, puede realizarse justo antes de que el valor sea enviado a la red. Así la mayor parte de los módulos del software de configuración son los mismos. Sólo difiere el módulo específico de bus de campo.

¿Cómo manejar la configuración basada en archivos de texto?

Sin embargo, lo que se ha descrito está basado en una extensión mucho mayor en FDT/DTM, y en particular, DTM. Como he mencionado antes, hay también otras maneras de describir el interfaz con un bus de campo, o incluso como se describe el interfaz de usuario para un dispositivo. Para Profibus hay (además de FDT/DTM) ficheros EDDL y GSD. Para DeviceNet hay archivos EDS.

EDDL no sólo describe interfaz de E/S y los parámetros configurables y leíbles, sino también el interfaz de usuario. Los archivos GSD describen el interfaz de E/S y los parámetros de arranque de un intrefaz de bus de campo. Device Net se encuentra entre estos dos. Los archivos EDS describen el interfaz E/S y también los parámetros accesibles on line. El factor común es que todos son archivos de texto y debe ser interpretados por el software de configuración.

¿Debe este software de interpretación de archivos de texto, ser un software independiente?

En Omron pensamos que ésto está lejos de lo ideal, ya que hay dispositivos de campo que son muy complicados y nada fáciles de configurar, por lo que se necesita un potente software de configuración. Por esto, el fabricante decidió crear un DTM para estos dispositivos.

Hay sin embargo muchos dispositivos que son más sencillos y un simple archivo de texto para su configuración es suficiente, como los archivos GSD y EDS. ¿Por qué no crear DTMs que puedan interpretar un archivos GSD o EDS? Para los ficheros GSD de Profibus, y Maestros de Profibus que Omron comercializa, existe en el mercado un software de configuración denominado CxProfibus. Cx Profibus consiste en un contenedor FDT y varios DTMs para los maestros, así como un Esclavo Generíco DTM que utiliza archivos GSD.

Para DeviceNet y más en concreto CIP (Common Industrial Protocol), se discutió dentro de la ODVA Software Tools jsig (Open DeviceNet Vendor Association Software Tools join special interested group), si los esfuerzos deberían dirigirse en encontrar herramientas de configuración basadas en Windows (ODVA:). Esto llevó a solicitar a la ODVA la FDT-jig (FDT-join interested group) a empezar a trabajar en un anexo para DeviceNet (CIP).

Algún trabajo ha sido ya llevado a cabo en los planteamientos de Software Tools jsig. Una mejora del concepto se presentó en el 10º meeting anual de ODVA en San Antonio, Texa. Más información se puede encontrar en el artículo “Enhanceing FDT to configure CIP base networks” publicado en la misma edición de Praxis Profiline en la página 60.

¿Qué clase de redes pueden esperar los clientes que sean soportadas por el software de configuración de Omron?

Desde el primer momento, Omron soporta archivos GSD, pero su contenedor FDT actualmente soporta todos los DTMs. No se basa en una red única específica. En un futuro próximo, Omron desarrollará otros DTMs para dispositivos de bus de campo, sin importar a qué red de bus de campo se conecten. Omron también soportará la configuración de buses de campo basados en archivos de texto.

Para archivos GSD es posible. Para DeviceNet (CIP) y archivos EDS es posible después de la creación de una anexo para este bus de campo en la especificación FDT/DTM. El trabajo empezó a principios del año 2005.

Todavía hay algo pendiente por resolver. La Organización de Usuarios de Profibus ha sugerido que EDDL sea también una posibilidad para configuración. Si hay suficiente demanda en el mercado, los proveedores deberán también soportar EDDL para la interpretación en formato DTM, como se ha hecho con otros métodos de configuración. La tecnología ya está preparada para ello.

Para los clientes, esto implica que los ingenieros de sus máquinas o de las fábricas no encontrarán muchas diferencias al usar diferentes buses de campo, ya sea Profibus, DevidceNet o cualquier otra clase de bus de campo, Omron lo soportará con y desde una única herramienta, interpretando archivos DTMs de texto o DTMs reales.

La manera en que FDT/DTM se ha especificado, garantiza a nuestros clientes que el interfaz de usuario del software de configuración de buses de campo con dispositivos diferentes sea idéntico. La tecnología que hay detrás del interfaz de usuario se hace cargo de todo. El cliente, simplemente crea y diseña sus máquinas.