Un configurador de buses de campo “universal”
01/11/2005
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.
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?
¿En qué consiste el esquema de comunicación anexo?
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?
Partes comunes y específicas del bus de campo
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.
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.
¿Cómo manejar la configuración basada en archivos de texto?
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?
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?
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.