Chris Zimmerman, director de Productos Integrados del grupo Molex Incorporated se pregunta: ¿pueden los nuevos estándares aportar el efecto “plug and play” a los sistemas de automatización industrial?

¿Se acuerda de la época en la que cada vez que tenía que conectar una nueva impresora al PC tenía que buscar el disco con el software original para instalar el driver de la impresora? A menudo, incluso tenía que ajustar la configuración del sistema operativo de forma manual para que el puerto del ordenador funcionara y estableciera la comunicación con la impresora. Y entonces comprobaba una y otra vez los cables creyendo que había un problema o que había hecho algo mal incluso cuando no era así. Se trataba de una tarea frustrante y de una pérdida de tiempo... como aún pasa en la actualidad con la puesta en marcha de equipos industriales.
Sin embargo, no tiene por qué ser así. A medida que los fabricantes de PC y periféricos han ido adoptando Ethernet y trabajando juntos en unos estándares, la conexión de los equipos y el engranaje de las aplicaciones se ha vuelto cada vez más sencillo y fácil. Hoy en día, se tarda un instante en instalar una nueva impresora, descargar y transferir archivos, integrar diferentes tipos de documentos o acceder al correo electrónico desde prácticamente cualquier parte del mundo donde se encuentre. Con el avance de Ethernet en las operaciones de fabricación, los desarrolladores de sistemas esperan que el mismo tipo de funcionalidad de los sistemas ofimáticos basados en Ethernet facilite aún más su trabajo de puesta en marcha de las fábricas. Una de las formas más importantes de llevarlo a cabo consiste en mejorar la interoperabilidad y facilitar la configuración necesaria para que los equipos y programas de software de diferentes fabricantes trabajen conjuntamente. 

Sin embargo, uno de los factores que limitan que un fabricante de equipos alcance la interoperabilidad es el ancho de banda de ingeniería que puede dedicar a las interfaces de software para la configuración y la parametrización. Incluso en Ethernet, con al menos cinco versiones estándares principales (Profinet, EtherNet/IP, Modbus TCP, EtherCAT y Fieldbus H1) y una gran cantidad de variantes menores y de sistemas heredados nos enfrentamos a una ardua tarea a la hora de tener una parametrización estándar cuando el controlador pretende conectar el equipo. Para complicarlo aún más, una vez establecida la conexión, cada controlador cuenta con un software de programación patentado que no suele soportar un determinado plug-in o la aplicación de un equipo (recuerde cómo se comporta un navegador web). Para el usuario, esto significa condenarse a cargar más software del fabricante, sumergirse en diversas ventanas todas ellas diferentes y volver a copiar datos en registros extraños para que todo funcione.     
Con todo, algunos fabricantes previsores encuentran formas para hacer avanzar la agenda de la interoperabilidad y desarrollar sistemas comunes que permitan a los equipos de diferentes proveedores hablar entre sí en la misma fábrica. Los grupos industriales trabajan para desarrollar estándares abiertos. Así, a la larga, los ingenieros tendrán más fácil la instalación de sistemas sin tener que usar métodos manuales pesados y torpes que permitan el uso de los equipos en la red.

El avance del proceso de fabricación
Un lugar donde buscar soluciones es el proceso de fabricación, que durante un tiempo ha fomentado el uso de contenedores de software FDT (Field Device Template), un estándar que permite a las empresas controlar la incorporación de gestores de plantillas de dispositivos estandarizados (DTM) de los fabricantes de equipos. Los DTM permiten a un equipo aparecer dentro de una aplicación en el nivel del sistema.
Por ejemplo, los dispositivos de campo como válvulas de control o medidores de caudal en una explotación agrícola en depósito se pueden calibrar y parametrizar para que todo el sistema funcione. Mediante los FDT, un DCS (sistema de control distribuido) puede introducir una aplicación de contenedor común que permita que un objeto de software commDTM de cada proveedor aparezca dentro del contenedor para configurar el dispositivo. La apariencia y la operabilidad entre los equipos se mantendrá constante, la interoperabilidad es excelente y el usuario ejecuta la configuración con la garantía de que ha colocado los parámetros adecuados en los campos correctos para todos los equipos, independientemente de la marca y del modelo.

En fabricación discreta, la adopción de esta tecnología ha sido lenta pero se ha visto favorecida por un movimiento para unir estándares concretos de funciones dispares como EDDL o FDT en un estándar potente único que suponga un método universal para conectar y compartir datos mediante OPC UA. El EDDL (lenguaje de descripción de quipos electrónicos estándar) se usa en los procesos principales de los fabricantes industriales para describir la información accesible en los dispositivos en el momento de la configuración. El OPC (OLE para control de procesos) se administra por parte de la Fundación OPC y es una forma de presentar los datos de un equipo producido en un formato estandarizado para que una etiqueta descriptiva de los datos se pueda usar en diversas aplicaciones de nivel superior.
El EDDL es especialmente importante para el diagnóstico y la parametrización. La virtud del OPC reside en la recopilación y visualización de los datos, mientras la ventaja del FDT radica en la configuración y la organización de la conexión del equipo. La combinación de estas dos características y su fusión en un único estándar es un objetivo altamente deseado por todos los usuarios. Un estándar combinado permitiría a los proveedores de equipos incluir un único plug-in estandarizado para todos los sectores y aplicaciones. Los sistemas de supervisión de cada proveedor podrían entonces navegar por el equipo, encontrar las etiquetas estandarizadas y mostrarse coherentemente en la aplicación del contenedor para que aparezcan como una pieza única en el software. Lo que estamos esperando es sencillamente la misma facilidad de uso de las impresoras modernas actuales.
El nuevo estándar combinado se llama FDI (Field Device Integration o integración de dispositivos de campo) y viene avalado por cinco organizaciones de red importantes y algunos de los nombres más importantes del sector (entre las empresas colaboradoras figuran ABB, Emerson Process Management, Endress+Hauser, Honeywell, Invensys, Rockwell Automation, Siemens, Smar o Yokogawa). Está previsto que se comercialice en verano de este año 2010, con una información preeliminar de los grupos de trabajo que ya muestran un gran entusiasmo. Aunque inicialmente se planeó para satisfacer los intereses de la industria de procesos, la amplitud del apoyo del fabricante y la presencia en el mercado de los colaboradores aportan la confianza para adoptarlo ampliamente en todas las aplicaciones industriales.

Barreras para la adopción
Mientras los beneficios de un sistema como este son evidentes, también existen barreras para su adopción. La primera es que algunas empresas de automatización han intentado tradicionalmente conservar a sus clientes mediante el uso de sistemas patentados, estructuras de software cerradas o variaciones de estándares. En un sistema patentado, los clientes tienen dificultades a la hora de adquirir determinados equipos de otros fabricantes debido a estas variaciones especiales. Un sistema abierto implica que las empresas compitan puramente por los méritos del valor que entregan. Algunos vendedores son recelosos a la hora de aplicar una estrategia como ésta, dadas las dificultades de la economía mundial y la facilidad de la retención histórica de los clientes basada en el encadenamiento por propiedad legal.
Otra barrera es sencillamente la resistencia al cambio. Algunas empresas acaban de integrar un estándar previo y son reticentes a enfrentarse a otra mejora del proyecto de forma inmediata. Otros han prescindido de personal ingeniero debido al clima económico actual y no tienen trabajadores para adoptar y aprender un nuevo sistema ahora mismo. Un factor adicional es que muchos clientes industriales son demasiado pacientes y toleran con frecuencia problemas de implementación.
Tras haber trabajado en diferentes sectores, me asombra descubrir que los fabricantes industriales toleran interfaces subestándares en sus sistemas de automatización. He observado ingenieros de sistemas trabajando durante dos semanas en la planta, luchando por lograr que algo funcione antes de rendirse y pasar a otro sistema diferente. No tolerarían estos hechos en el caso de haber adquirido un producto en oferta, así si no pudieran hacerlo funcionar en treinta minutos, lo devolverían inmediatamente a la tienda y pedirían la devolución del importe. Quizá necesitemos algo de esta indignación justificada para el mundo de los sistemas industriales.

Soluciones disponibles
Sabiendo esto, los vendedores y usuarios ya cuentan con algunas opciones para conseguir que los sistemas de automatización funcionen mejor en entornos de fabricación discreta sin esperar a la mejora y adopción de estándares adicionales. Algunos fabricantes de sistemas de automatización ya están abriendo diferentes partes de su software para dejar que dispositivos de terceros se comuniquen directamente con sus equipos en la red. Esto no es lo mismo que contar con un estándar universal y abierto, pero al menos permite a empresas asociadas entrar en más lugares de terceras partes.
Por ejemplo, Rockwell Automation permite el desarrollo de instrucciones adicionales (AOI) por parte de fabricantes de equipos. Se trata de elementos de software parcialmente estandarizados que permiten a terceras partes incluir diversas líneas de código de instrucciones que indiquen al sistema de software cómo preparar sus equipos en una red RA. Esto permite el desarrollo de más parámetros descriptivos en lugar de usar meras opciones de direccionamiento. También logra que el equipo de un tercero se comporte más como otros equipos en el sistema de Rockwell.
Otra opción es que los vendedores terceros trabajen con un RA para crear perfiles adicionales completos mediante tablas de parámetro para sus equipos, que luego serán como equipos Allen-Bradley en el sistema de software. Un proveedor tercero no puede lograrlo por sí solo, debe proporcionar cierta información a Rockwell Automation y recopilarla como un objeto para el sistema de software, pero al menos los perfiles ofrecen un acceso constante e integrado a los usuarios.
Rockwell también permite a vendedores terceros exportar lógica desde el programa de control a través de DeviceLogix®, un sistema que permite al proveedor tercero aceptar el objeto lógico central fuera del entorno de programación de Rockwell Automation e incorporarlo a su equipo para que se pueda programar en la red. Esto permite a un bloque de entrada/salida local ejecutar una lógica sencilla en el equipo en lugar de fuera en el controlador. El dispositivo tercero se puede programar de forma que sea muy familiar al usuario RA. Se trata de un pequeño paso, pero muy útil en el camino hacia la integración total.
Otro buen ejemplo de elementos de software abierto de Rockwell Automation es RSLinx®, un servidor de comunicación que ofrece conectividad del equipo en la planta para gran variedad de aplicaciones de software de Rockwell, lo que permite al sistema hablar de forma remota con los equipos de campo. Molex Incorporated usa RSLinx a través de una interfaz DLL que les permite conectarse a sus equipos a través de caminos RA. Mientras el usuario sigue usando una herramienta de un tercero para preparar su equipo, rastrear la configuración del parámetro y establecer la configuración a través de los cuadros de encaminamiento que Rockwell ha formado mediante RSLinx implica mayor integración y es más fácil de llevar a cabo que instalar nuevas conexiones. Un ingeniero de sistemas puede usar RSLinx como un mecanismo “de salto” para reconocer cada dispositivo de forma automática. Mecanismos como este implican buenos pasos intermedios mientras avanzamos hacia un estándar de Ethernet abierto común.
Aunque hemos puesto como ejemplo a Rockwell Automation, muchos de los principales proveedores de automatización cuentan con formas similares para que dispositivos de otros fabricantes se conecten a sus sistemas, siempre que dispongan de tiempo y dinero para llevarlo a cabo de forma individual. Dar un paso más en este proceso —como el uso de estructuras FDI como estándar del sector común— implicaría que los vendedores dejarían de enfrentarse a estas grandes barreras de tiempo y dinero para ser verdaderamente interoperables en los diversos sistemas del mercado. Los ingenieros no tendrían que escribir instrucciones individuales para cada sistema de los diferentes fabricantes. La innovación y la facilidad de uso podrían avanzar aún más si el tiempo y el dinero malgastado en soportar enfoques de competidores se invirtieran en su lugar en aportar más facilidad de uso. Los costes de apoyo tecnológico disminuirían si todos los actores del mercado se centraran en los matices de bajo perfil del sistema común. 
Tener una única plataforma pone metas para que las personas puedan innovar. En lugar de preocuparse por establecer conexiones básicas y poder comunicarse con un dispositivo, los desarrolladores de sistemas pueden usar una plataforma común para centrarse en optimizar sus aplicaciones y conseguir que sean más sencillas y fáciles de usar.
La diferencia entre los sistemas abiertos y los patentados en la automatización industrial es como la revolución que vemos en productos como el iPhone o la Blackberry en la actualidad. Es fácil desarrollar aplicaciones para estos equipos porque son sencillos y muy abiertos. Como resultado, empresas terceras pueden ayudar a los fabricantes principales mediante una gran cantidad de aplicaciones que mejoren la experiencia del usuario, muchas de los cuales acaban siendo imprescindibles y el mercado las acaba esperando. La innovación florece y se acelera a medida que los desarrolladores ganan confianza en la plataforma.
Asimismo, para un ingeniero de automatización industrial que debe crear diferentes aplicaciones para sistemas de Emerson, Rockwell o Siemens su motivación no será concebir aplicaciones vanguardistas, sino que pasará el día intentando mantener una conectividad básica. Si tiene de repente libertad para innovar por encima de lo básico porque las conexiones y el formato ya están dados, la optimización del sistema y la satisfacción del cliente ascenderán de forma espectacular. Depende de todas aquellas personas involucradas en la automatización industrial conseguir que esto sea una realidad.
Molex apoya con vigor el desarrollo de un enfoque integrado. Tanto nosotros como otras empresas hemos adoptado FDT y OPC y avanzamos para unirlos en el estándar FDI. Con una dilatada historia de integración de productos con aquellos de diferentes proveedores de sistemas, apreciamos los retos y los beneficios que aportará el cambio hacia el FDI para mejorar la experiencia de los clientes. Queda claro que el trabajo será mucho más sencillo con la adopción de una plataforma común como el FDI.
Molex es una marca registrada de Molex Incorporated.
DeviceLogix y RSLinx son marcas registradas de Rockwell Automation.
Los demás nombres de productos y empresas son marcas comerciales de sus respectivos propietarios.

Más información o presupuesto