El camino histórico y tecnológico desde el control en el campo, de Foundation Fieldbus, hasta computación en el borde y Ethernet APL.

CiF

Una de las características más innovadoras que ofrecía el protocolo de bus de campo Foundation Fieldbus, el cual está basado en el estándar IEC 61158-2, era la conocida como “Control in The Field” o “CiF” (‘control en el campo’).
El objetivo de esta tecnología era permitir la inclusión de bloques con funciones de control en la electrónica de los dispositivos de campo Foundation Fieldbus, de modo tal que los lazos de control se pudieran configurar y ejecutar sin la necesidad de contar con un controlador.
Esta propuesta de control local se parece inicialmente a un retorno al modelo de control utilizado en los antiguos sistemas de control neumático. Si bien se siente como un retroceso a las épocas antiguas, el concepto ofrecía posibilidades interesantes de aplicación.
El paradigma del concepto de control basado en DCS consistía en concentrar el procesamiento de los lazos de control en unos pocos controladores de alto rendimiento. La mayoría de las aplicaciones DCS utilizan uno o dos controladores.
Bajo este modelo de control, sería ventajoso evitar sobrecargar el procesador del controlador principal, y este objetivo se podría lograr mediante la descentralización que permitía la funcionalidad CiF incluida en Foundation Fieldbus.

Figura 1. Topología tradicional de un DCS
Figura 2. Topología de una aplicación con control en el campo
Figura 3. Topología CiF totalmente redundante

Un ejemplo de una aplicación CiF

Un ejemplo simple de una aplicación que use CiF podría ser el siguiente: imaginemos una válvula que controla el flujo de líquido a un tanque. La válvula está conectada al mismo segmento de bus de campo Foundation Fieldbus que un sensor de nivel ubicado en el tanque, el cual monitorea el nivel del líquido. Si el firmware de la válvula de control incluía un bloque de función PID, sería posible configurarlo para utilizar los datos del sensor de nivel para cerrar un lazo de control; el cual, por ejemplo, se podría encargar de mantener un nivel constante en el tanque o evitar su sobrellenado o su vaciado.
La tecnología CIF se puede emplear en una variedad de configuraciones de control (figura 3). Se puede utilizar en combinación con el controlador o de forma independiente. Es decir, el bucle de control se podría configurar en el controlador principal y en el campo como una medida de redundancia. O se podría implementar solo en el campo para ahorrar capacidad de procesamiento en el controlador, o para garantizar un tiempo de respuesta más rápido en la ejecución del lazo.
Los videos de demostración típicos de la era del bus de campo mostraban la simulación de la falla de un controlador en una aplicación Foundation Fieldbus y cómo el bucle de control continuó funcionando después, con el bloque de función ejecutándose en el campo sin interrupciones.

Entonces, ¿por qué esta característica no se usó ampliamente?

Hay algunas razones, pero las principales se pueden resumir de la siguiente manera:

  • Nunca hubo un acuerdo sobre qué tipo de bloques de función se suponía que debían estar disponibles en qué tipo de dispositivos de campo, por lo tanto, en el caso de una falla del dispositivo, solo una unidad de reemplazo exactamente igual podría mantener el papel del dispositivo en la aplicación CiF.
  • Los dispositivos Foundation Fieldbus de esa época tenían procesadores comparativamente potentes en comparación, por ejemplo, con dispositivos de 4-20 mA o Hart, pero no eran lo suficientemente poderosos como para implementar estrategias de control avanzadas.
  • La lenta velocidad de transmisión de los buses de campo compatibles con el estándar IEC 61158-2 (31,25 kbps) implicaba que era necesario un trabajo cuidadoso en la configuración de los tiempos de sincronización de los ciclos.
  • Una arquitectura de control descentralizada requiere personal con mayor capacitación y experiencia, tanto en ingeniería como en mantenimiento.
Figura 4. Concepto original de Foundation Fieldbus, que integra capas físicas HSE y H1
Figura 5. Los buses de campo antiguos y/o de terceras partes se pueden integrar en una red Profinet mediante proxies.

Una opinión

Desde mi punto de vista, la razón principal de la eventual desaparición de la tecnología Foundation Fieldbus se debió a la negativa de los proveedores de sistemas de control a adoptar la implementación del protocolo en Industrial Ethernet (HSE o ‘High-Speed Ethernet’, ‘Ethernet de alta velocidad’) como red troncal en sus sistemas de control. Los proveedores de DCS habían invertido cantidades masivas en el desarrollo de protocolos Ethernet patentados determinísticos en tiempo real y, por lo tanto, había poco o ningún interés en reemplazar estos protocolos por una implementación abierta que brindara interoperabilidad entre las ofertas de los competidores.
El negocio principal de los proveedores de DCS no es en realidad la venta de sistemas de control, sino la venta de actualizaciones de sistemas de control y los servicios postventa. La interoperabilidad de sistemas va en contra de este modelo de negocio.
Debido a esta adopción incompleta de la tecnología Foundation Fieldbus, las instalaciones que usaban dicho protocolo eran de hecho pequeñas islas FF interconectadas mediante las redes troncales basadas en Industrial Ethernet patentadas que utilizaban los proveedores de sistemas de control y DCS.

Las cosas más simples tienden a durar más que las cosas complejas

La tecnología Foundation Fieldbus capaz de CiF vino y se fue. Su rival contemporáneo, Profibus PA, ha disfrutado de una vida útil más larga gracias al uso de una arquitectura Maestro/Cliente menos pretenciosa, a la disponibilidad de una ruta de migración hacia Industrial Ethernet proporcionada por la tecnología Profinet y a la inclusión de un método estandarizado para la integración de redes heredadas en Profinet utilizando tecnología Proxy.
Al mismo tiempo, el mundo de TI estaba desarrollando el concepto de “edge computing” (‘computación de borde’). A lo largo de los años, gracias a la Ley de Moore, las capacidades del hardware de computación han ido creciendo exponencialmente, tanto de hecho que la potencia de cálculo disponible en dispositivos comunes como teléfonos inteligentes o consolas de juegos rivaliza con el rendimiento de las supercomputadoras disponibles hace veinte años. Como ejemplo de lo potente que es el hardware actual, considere este hecho: la primera computadora en alcanzar 1 teraflop fue la ASCI Red de Intel en 1997. En 2008 una GPU ATI Radeon 4800 superó esa capacidad de 1 teraflop. En los últimos treinta años, la potencia informática ha crecido unas diez mil veces.

Figura 6. La Ley de Moore para la potencia de procesamiento
Figura 7. La Ley de Nielssen para el ancho de banda disponible en Internet
Figura 8. Los dispositivos edge en la jerarquía de la nube

Una cuestión de ancho de banda

Mientras tanto, como predijo la Ley de Nielssen, el ancho de banda disponible para el acceso a Internet también ha experimentado un crecimiento dramático, pero si comparamos el crecimiento del ancho de banda con la potencia de procesamiento durante la misma cantidad de tiempo (últimos diez años) nos encontraremos con el hecho de que el ancho de banda aumentó en un factor de 57 y la potencia de cálculo en un factor de 100.
Esto significa que el factor limitante para el avance continuo de digitalización de nuestros procesos es el ancho de banda, no la potencia de cálculo. La tendencia actual a realizar el procesamiento de datos en plataformas basadas en la nube encontró límites en la vida real cuando el costo de subir datos sin procesar se volvió significativo. Todos los datos adicionales generados por las aplicaciones IoT e IiOT iban a superar la capacidad de ancho de banda de Internet.

‘Edge computing’

La solución vino con un nuevo paradigma de computación que se conoció como “computación de borde” (‘edge computing’). La idea era utilizar un modelo de computación distribuido que hiciera que los recursos informáticos y de almacenamiento de datos estuvieran más cerca de las fuentes de datos. La idea se originó en las redes distribuidoras de contenido que se crearon en la década de 1990 para brindar contenido web y video online a los usuarios finales.
Las computadoras de borde administran el procesamiento de datos en el último kilómetro de la red; por lo tanto, experimentan un retraso significativamente menor que las computadoras en la nube. El propósito de la computación de borde es reducir la latencia mientras se realizan operaciones en tiempo real.

La llegada de los controladores híbridos

La versión de la industria de la automatización del concepto de computación de borde aprovechó el desarrollo y la disponibilidad de controladores híbridos o PAC (‘controladores de automatización programables’, por sus siglas en inglés).
Todavía hay un debate en curso sobre esta denominación, pero la idea general es que un controlador híbrido es un dispositivo que puede cumplir el papel de un PLC, el cual es realizar funciones de control estándar, lo que involucra el manejo de señales discretas o digitales y continuas o analógicas, y adicionalmente son capaces de realizar un control avanzado utilizando nuevas técnicas de control, tales como el control adaptativo, la inteligencia artificial, el aprendizaje automático o la lógica difusa.
Para hacer esto, los controladores híbridos cuentan con CPU de alto rendimiento y grandes recursos de memoria que superan los de los PLC tradicionales y se acercan a las capacidades de los controladores de tipo DCS de hace unos años.

Computación de borde en la automatización de procesos

En la última década ha habido un creciente interés en el uso de arquitecturas de control distribuido en la industria de la automatización con el propósito de aumentar la funcionalidad, la modularidad y la escalabilidad.
El paradigma de la computación de borde aplicado a la industria del control de procesos generó emprendimientos tales como la iniciativa OPAS (‘sistema abierto de automatización de proceso’, por sus siglas en inglés). Este enfoque del control de procesos se basa en el uso del nodo de control distribuido (DCN, por sus siglas en inglés), como componente básico del concepto de automatización de procesos basados en estándares abiertos.

DCN

La descripción del DCN se parece a un dispositivo de borde industrial, es decir un dispositivo que puede administrar tareas de control local y también puede preprocesar datos cerca del origen. Al hacer esto, solo los datos relevantes se transfieren a los repositorios de datos basados en la nube, lo que reduce el ancho de banda requerido y elimina la latencia inherente de las aplicaciones basadas en la nube que las hace inadecuadas para fines reales.

Figura 9. Ejemplo de un PAC
Figura 10. Arquitectura simplificada del concepto OPAS
Figura 11. Arquitectura completa del concepto OPAS

Saber más

Si quiere saber más sobre la iniciativa OPA, más información aquí.
Si siente curiosidad por Ethernet-APL, información adicional aquí.
Y, por último, si estás interesado en cómo se relaciona la tecnología HART con Ethernet-APL, puede consultar aquí.

Autor: 

Mirko Torres Contreras


Francisco Cotrina

Por AADECA

Deja una respuesta

Tu dirección de correo electrónico no será publicada.

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

EnglishFrançaisDeutschPortuguêsEspañol