Una breve historia de la gestión de dispositivos
Parte 2: del lenguaje EDDL al concepto FDT/DTM.
Entonces algo sucedió, comencé a trabajar en un proyecto temprano basado en Profibus PA que presentaba acopladores de segmento y acopladores de válvulas de Pepperl + Fuchs, dispositivos de campo Endress + Hauser, válvulas de control Samson y un sistema RIO para recopilar las señales que no se podían conectar a través de Profibus.
Y de repente me di cuenta de la gran idea que era este concepto FDT/DTM.
Los gráficos eran bastante crudos. Y si se requería contar con un acceso centralizado a todos los dispositivos utilizados en una sola planta, realmente se necesitaba un DCS o una herramienta de gestión de activos del proveedor del sistema de control. Finalmente, este nivel de integración a menudo requería el uso de instrumentación inteligente de un solo proveedor.
Proporcionaba una estructura jerárquica estandarizada, en forma de árbol único, que hacía posible navegar a través de los dispositivos de campo, sistemas RIO, acondicionadores de señal y dispositivos de diagnóstico de una manera que era familiar para cualquier usuario de PC: el concepto FDT/DTM hizo que la gestión de activos fuera tan fácil como usar el administrador de dispositivos de su PC.
Y al igual que en el administrador de dispositivos de Windows, cada subárbol correspondía a una rama de dispositivos, y cada rama compartía el mismo protocolo de comunicaciones.
- El componente FDT. También conocido como la aplicación marco, su propósito es trabajar como un entorno de tiempo de ejecución para DTM. El componente FDT puede funcionar en modo independiente o también se puede integrar en una herramienta de ingeniería/programación DCS o PLC, o en una herramienta de gestión de activos.
- El componente DTM. El DTM es un componente de software que permite la interacción entre dispositivos de campo inteligentes, hardware de comunicaciones y controladores en una red digital. Un DTM funciona como una interfaz o contenedor para todos los parámetros, funciones, interfaz de usuario, etc. del dispositivo, creando así una representación de las características del dispositivo a través de una pantalla gráfica. Los DTM son suministrados por el fabricante con el dispositivo de campo correspondiente.
Internamente, los DTM funcionan como servidores, proporcionando información y funcionalidad según lo requiera el componente FDT o la aplicación marco, que funciona como cliente, solicitando la información que será empleada por las aplicaciones cliente que este contiene.
La aplicación marco puede intercambiar información con los DTM para parametrización, diagnóstico y aplicaciones específicas del dispositivo.
Estos canales crean una representación de las fuentes de datos contenidas en el dispositivo de campo.
Hay dos tipos o categorías principales de DTM:
- DTM de dispositivos. Empleados para dispositivos de campo estándar, contienen el software de aplicación correspondiente para interactuar con dispositivos inteligentes específicos o genéricos, como un transmisor de presión.
- DTM de comunicación. Se utilizan para la integración y configuración de hardware de comunicaciones específico, es decir, un módem HART.
- DTM de dispositivos estándar.
- DTM de puerta de enlace (puerto). Una categoría especial de DTM que representan un dispositivo que conecta diferentes segmentos de bus de campo como, por ejemplo, un acoplador Profibus DP/PA o un puerto IO-Link para conexión con una red Profinet. Un DTM de puerta de enlace se puede ver como una combinación de un DTM de comunicación y un DTM de dispositivo. Un dispositivo conectado a la puerta de enlace física aparecería como un DTM secundario, conectado al DTM de puerta de enlace a través de un canal de comunicaciones. Esta propiedad está detrás del concepto "comunicaciones anidadas", que se discutirá más adelante.
- DTM de dispositivo compuesto. Otra categoría especial de DTM que representa dispositivos con una estructura modular compuesta por varios módulos de hardware que se pueden conectar a ranuras físicas. Esta disposición de hardware, típica de los sistemas de E/S remotas, puede representarse mediante una jerarquía de DTM.
Para las tareas de diagnóstico, se seleccionó la recomendación NE 107 de NAMUR, lo que garantiza una apariencia coherente en todas las aplicaciones Frame relacionadas con el diagnóstico.
La tecnología funciona como una capa de abstracción que oculta al usuario las complejidades de las traducciones de protocolos y las interfaces de capa física. Dado que la tecnología FDT/DTM define qué son las interfaces, pero no cómo funcionan, el proveedor del DTM es libre de implementar esas interfaces sin restricciones.
- Algunos desarrolladores han creado DTM para dispositivos que no tienen soporte DTM nativo de su fabricante, como DTM de terceros para los equipos Siemens DP/PA Link y los sistemas de E/S remotas ET200.
- También existen DTM intérpretes. Estos son DTM especiales que interpretan las descripciones de los dispositivos de los archivos DD o EDD en tiempo de ejecución, lo que permite la administración de dispositivos que no tienen soporte DTM nativo pero que admiten descriptores de dispositivos DD, EDD o IODD.
Hasta la fecha, la tecnología FDT ofrece soporte para diecisiete protocolos de comunicación estándar.
Hoy en día damos estas cosas por sentado, pero ese proyecto fue el primero en el que pude acceder a todos los componentes y realizar su instalación, configuración y puesta en marcha desde un solo paquete de software.
Al utilizar Pactware o cualquier otra aplicación marco que cumpla con la especificación FDT, si tuviera algún dispositivo de campo, la puerta de enlace de comunicaciones requerida y sus DTM correspondientes, su configuración y puesta en marcha podría realizarse de forma local o remota. En ambos casos, la experiencia del usuario era la misma: la pantalla principal de la aplicación Frame, que presentaba un árbol jerárquico con nodos que representaban las puertas de enlace de la comunicación y subnodos que representaban los dispositivos de campo.
Este era el mismo tipo de estructura de árbol que los usuarios de PC habían estado empleando para trabajar en sus máquinas desde la introducción de la GUI. De repente, la planta tenía el equivalente del administrador de dispositivos de Windows. Y no era necesario gastar una fortuna en hardware y software para DCS, ya que las aplicaciones marco integradas en las herramientas de programación e ingeniería de los PLC pronto se convirtieron en algo común.
FDT/DTM se convirtió en un ecualizador entre las soluciones DCS/PCS y las soluciones PLC, al menos desde el punto de vista de la integración de dispositivos.
Además, aunque el énfasis principal de FDT se ha centrado en la industria de la automatización de procesos, algunos proveedores de equipamiento de automatización de fábricas eligieron la tecnología FDT/DTM para equipos específicos de FA, como accionamientos, arrancadores suaves y redes de sensores discretos. Este tipo de aplicaciones muestran la flexibilidad que ofrece esta tecnología.
La ventaja de poder administrar dispositivos conectados a, por ejemplo, una red Control Net, una red Profibus y una red Modbus TCP, todas ubicadas en la misma planta, utilizando la misma aplicación única fue excelente, pero también presentó algunos problemas sutiles.
La implementación de la arquitectura interna cliente/servidor, descrita anteriormente, para las comunicaciones entre los DTM y el FDT se logró mediante el empleo del estándar de interfaz COM (del inglés, ‘modelo de objeto común’) de Microsoft, XML y tecnologías Active X para la interfaz de usuario y el intercambio de datos. Por lo tanto, dependía en gran medida de las tecnologías de Microsoft. Si Microsoft actualizaba la interfaz COM, las cosas podrían salir mal.
Cualquier problema requería una versión actualizada de cualquier DTM en conflicto, lo cual no es una situación conveniente. Además, el nivel de seguridad que se implementó consistió en la configuración de seguridad según el rol del usuario. Por supuesto, esta fue en una época anterior a la actual, en la que los problemas y políticas de ciberseguridad aún no tenían la importancia que tienen hoy en día.
Pero se estableció el concepto básico, y la estructura de árbol jerárquico empleada como metáfora de la pirámide jerárquica de automatización física era flexible, amigable y replicaba el hardware real de una manera que era bastante intuitiva.
La tecnología FDT/DTM suele compararse con EDDL, pero desde mi punto de vista son dos herramientas diferentes. EDDL funciona como un archivo Profibus GSD, es decir, un archivo de texto que describe las características de un dispositivo para informar a la herramienta de configuración qué parámetros se pueden ajustar. FDT/DTM funciona como la combinación de un navegador web y páginas web dinámicas, la aplicación marco muestra el contenido de los DTM y permite al usuario interactuar con el dispositivo de campo real o con una representación virtual del mismo.
La interfaz de usuario empleaba Windows Presentation Foundation y WinForms. Fue una actualización que abrazó la tendencia hacia componentes de software libres y de código abierto que eventualmente hicieron de FDT/DTM un concepto a prueba de futuro. Y al dejar atrás la tecnología basada en COM y DCOM, FDT/DTM se convirtió en una plataforma de software más estable y robusta.
Con esta característica se crean dos grandes ventajas:
- Es posible la implementación de repositorios de DTM centralizados en servidores.
- Los DTM ahora se pueden implementar utilizando soluciones móviles.
La segunda característica también depende del uso de una arquitectura distribuida. Dado que las interfaces de usuario, las lógicas de negocio y las aplicaciones marco pueden ejecutarse en diferentes dispositivos, es posible utilizar dispositivos móviles para ejecutar aplicaciones marco. Por lo tanto, cualquier dispositivo móvil puede funcionar como una estación de trabajo de gestión de activos o como un configurador portátil.
El soporte de protocolos nuevos se habilita mediante la instalación de cualquier DTM que los usara. Anteriormente esto solo era posible instalando los DTM de comunicación específicos del protocolo y los DTM de puerta de enlace. Una gran cantidad de proveedores de DCS y PLC comenzaron a emplear la tecnología FDT/DTM integrada en su software de ingeniería para mayor simplicidad.
En lugar de emplear documentos basados en XML para el intercambio de datos, la versión 2.0 utiliza objetos .NET. Este es un método más rápido porque los documentos XML deben analizarse y reestructurarse cada vez que se intercambian. Mediante el uso de objetos .NET, los DTM se convierten en objetos que funcionan como representaciones digitales de los dispositivos de campo reales.
De este modo, los DTM se vuelven más flexibles y, en consecuencia, las interfaces de usuario se pueden ejecutar en una estación de trabajo mientras que la lógica del dispositivo se ejecuta en un servidor. La estrecha relación entre un dispositivo y su DTM correspondiente permite la detección automática del DTM correcto para un tipo o versión de dispositivo específico. En la versión 1.2, la asignación de DTM se realizaba manualmente, una práctica que causaba problemas debido a la posibilidad de asignar DTM incompatibles con los dispositivos.
Para garantizar la interoperabilidad entre todos los componentes de software, se creó un conjunto de componentes comunes para controlar aspectos como el comportamiento de la interfaz. Este enfoque garantiza la interoperabilidad y simplifica la creación de DTM, reduciendo así los costos de desarrollo.
El uso opcional de un servidor OPC UA dentro de la aplicación marco requiere la compatibilidad entre el modelo de información utilizado por los DTM y los modelos de información utilizados en el servidor OPC. Esto crea una representación de los DTM usando el modelo de información OPC UA. Este modelo expone los datos de los nodos representados por los DTM utilizando los servicios OPC UA, poniendo los datos a disposición de cualquier cliente OPC UA.
Las prácticas de administración de dispositivos experimentaron un cambio dramático. Desde la pequeña herramienta de configuración de dispositivos que FDT/DTM era en sus inicios, el concepto ha crecido en escala para convertirse en una arquitectura de middleware disponible en toda la planta, basada en el concepto servidor/cliente, que hace posible el acceso a los datos en toda la pirámide de automatización completa.
FDT se ha convertido en un estándar ampliamente implementado, con millones de DTM de dispositivos en uso compatibles con una variedad de entornos de huésped FDT. Ha sido adoptado como estándar global por IEC (IEC 62453), ISA (ISA/ASNI 103) y GB-T 29618-2017. La gama de aplicaciones que utilizan la tecnología FDT va desde aplicaciones de escritorio independientes, aplicaciones móviles personalizadas, integradas en software de configuración o ingeniería de PLC o DCS e integradas en entornos OPC UA.
Otro salto se estaba gestando con la versión 3.0, y esta vez el objetivo estaba en las nubes.
Quiero expresar mi agradecimiento a Maggie Carlson y Steve Biegacki, del FDT Group, por la colaboración y el apoyo en la preparación de este artículo.
Nota del autor.
Phoenix Contact patrocina este artículo. Las opiniones expuestas en este artículo son estrictamente personales. Toda la información requerida y empleada en este artículo es de conocimiento público.
Sobre el autor
Mirko Torrez Contreras es un consultor y entrenador especializado en automatización de procesos. Mirko ofrece consultoría en automatización de procesos, y consultoría y entrenamiento en redes industriales y protección contra explosiones. Está reconocido como Consultor Asociado en el Centro Internacional de Capacitación y Competencia de Profibus ubicado en Argentina (http://profibus.com.ar/). Además, presta servicios de escritura y traductorado técnicos (inglés o español).