Modernización de la Medición Electrónica de Flujo con MQTT
MQTT resuelve los desafíos de la Medición Electrónica de Flujo (EFM).


Modernización de la Medición Electrónica de Flujo con MQTT

MQTT resuelve los desafíos de la Medición Electrónica de Flujo (EFM)


Por Arlen Nipper, presidente y director de tecnología de Cirrus Link

Una breve historia de EFM

Como preparación para una discusión sobre la modernización de la Medición Electrónica de Flujo (EFM), comencemos con un vistazo rápido a su historia. En 1980 estaba en Amoco Oil, y EFM, o medir la cantidad de petróleo y gas que fluye a través de un oleoducto, se calculó con registradores de gráficos redondos.

Un alfiler registraría la presión y la temperatura en el transcurso de un mes y luego alguien recolectaría físicamente los gráficos redondos si la tinta no se hubiera agotado o no hubiera sido comido por los ratones. Luego, los ingenieros integrarían la temperatura y la presión con una calculadora para determinar el volumen.

Puede imaginarse la oficina de un ingeniero con 200 de estos gráficos de papel tirados tratando de dar sentido a los datos. En algún momento a principios de los 80, alguien se dio cuenta de que podía medir los datos electrónicamente e integrarlos en una computadora. Finalmente, el Instituto Americano del Petróleo (API) publicó un estándar que decía que si va a medir el petróleo y el gas y luego venderlo, la medición debe ser muy precisa.

Hubo una prisa por automatizar EFM para una mejor medición, por lo que en los primeros días se instalaron millones de computadoras de flujo en empresas de todo el mundo. Durante los siguientes 30 años hubo algo así como una docena de fabricantes diferentes y una docena de protocolos para EFM.

Como resultado de estas docenas de soluciones, hoy vemos una infraestructura heredada heterogénea para EFM con muchas soluciones propietarias específicas del cliente. Algunas empresas de petróleo y gas tienen miles de computadoras de flujo; por lo tanto, la actualización a una nueva tecnología no es fácil. Un técnico tiene que salir para desconectar / desinstalar las computadoras de flujo y luego reinstalar el equipo nuevo. Cuando busca decenas de miles de dólares para modernizar cada computadora de flujo, el costo suele ser prohibitivo.

Sin mencionar que las computadoras de flujo en el campo hoy en día son muy precisas. Trabajan. Todos sabemos que si no está roto, no lo arregles. El problema no es la precisión, sino la coherencia.

Los desafíos con diversos tipos de datos EFM

Las computadoras de flujo de hoy en día realizan una doble función con múltiples hosts y múltiples tipos de datos, lo que no es propicio para los procesos SCADA típicos. Desde el punto de vista de las operaciones, los datos operativos en tiempo real incluyen datos de configuración, alarmas, eventos e historial. Según el estándar API, estos puntos de datos son atómicos, lo que significa que deben permanecer juntos, y debe demostrar que todos se recopilaron al mismo tiempo, lo cual es increíblemente desafiante. A estos puntos de datos se accede por protocolo.

En el otro lado de la computadora de flujo está la caja registradora que dice - en la última hora este gasoducto entregó x barriles de petróleo ox pies cúbicos de gas natural. Además, hace dos horas alguien cambió la calibración de la computadora de flujo. A este tipo de datos contables se accede de forma diferente pero desde el mismo instrumento.

Actualmente, EFM presenta varios desafíos, pero la principal preocupación es que la mayoría de las redes existentes no tienen el ancho de banda para satisfacer todas estas demandas de datos. Las empresas están tomando decisiones que no deberían tener que tomar: tienen que decidir qué datos dejar varados, ya que no pueden acceder a todos. Están sacrificando la disponibilidad de datos debido al ancho de banda.

La razón por la que las redes no tienen suficiente ancho de banda es porque los protocolos EFM son de sondeo / respuesta. En la red, el usuario envía una encuesta, espera a que la computadora de flujo genere una respuesta, la respuesta regresa y luego pasa a la siguiente computadora de flujo. Los protocolos de sondeo / respuesta tienen límites porque no puede sondear lo suficientemente rápido en la red y muchos datos muy valiosos se quedan varados en el campo.

La conclusión es que debido al estado de EFM, los clientes tienen que elegir qué datos quieren dejar varados en el campo, y eso no es algo bueno.

Nuevos requisitos para EFM

Incluso si los clientes mantuvieran el status quo, está claro que hay desafíos con EFM. Ahora, ¿qué pasa con los nuevos requisitos? La industria está repleta de inteligencia artificial, optimización de procesos, aumento de la producción y más. Todas estas actividades significan múltiples consumidores de datos, más presión sobre el ancho de banda y más conjuntos de datos en silos.

La buena noticia es que para habilitar estas nuevas tecnologías, las empresas no necesitan volver a instrumentar todo su sistema. Todo el equipo está funcionando bien, solo necesitamos tener un mejor acceso a los datos.

Ahora, una planta puede mejorar un poco su red y obtener un poco más de datos. Pero estos nuevos requisitos exigen una magnitud mayor de datos y más rápido que nunca. Quizás un fabricante estaba pidiendo un conjunto de 5 variables de proceso, pero ahora quieren 100. En lugar de cada hora, quieren 100 cada minuto. Este tipo de mejoras son posibles, pero es necesario realizar cambios.

Una vez que un cliente logra este aumento en los puntos de datos por orden de magnitud, las funciones avanzadas se convierten en un biproducto de los datos. Si ve datos cada minuto, puede habilitar la inteligencia artificial y el mantenimiento predictivo y otras tecnologías nuevas utilizando esos datos para obtener inteligencia real.

Trabajé con un cliente que implementó los cambios que estamos a punto de discutir y pasó de obtener datos una vez por hora a una vez por minuto. Para lograr ese tipo de visibilidad, debían volver a capacitar a sus operadores porque están viendo datos en vivo y nunca antes habían visto eso. Pueden ver cómo está operando realmente el oleoducto casi en tiempo real. Olvídese de la optimización o la inteligencia artificial, solo tener más visibilidad les permite hacer un mejor trabajo operando los activos que tienen hoy.

MQTT resuelve los desafíos de EFM

Si nos olvidáramos de los últimos 35 años de tecnología EFM y elimináramos cualquier noción preconcebida e inventáramos algo nuevo hoy, ¿cómo querríamos que funcionara? Querríamos una computadora de flujo conectada a una red TCP / IP moderna. Querríamos conectarnos, autenticarnos y luego encontrar todo lo que queremos saber. Debería ser así de simple.

La buena noticia es que hay una manera de hacerlo de manera eficiente, utilizando todas las ventajas de las redes TCP / IP subyacentes que tenemos hoy. Resulta que no tenemos que usar encuesta / respuesta, hay una forma mejor.

Co-inventé MQ Telemetry Transport (MQTT) en 1999 con el Dr. Andy Stanford-Clark de IBM como un estándar abierto para ejecutar una tubería. El proyecto era para Phillips 66 y querían usar las comunicaciones VSAT de manera más eficiente para su sistema SCADA de misión crítica en tiempo real. Varios consumidores de datos querían acceder a la información en tiempo real (Figura 2).

Figura 2: Phillips 66 tenía varios consumidores de datos y varios productores de datos. MQTT nació para solucionar el problema.

MQTT es un protocolo de mensajería de publicación / suscripción, extremadamente simple y ligero. Está diseñado para dispositivos restringidos y redes de bajo ancho de banda, alta latencia o poco confiables. MQTT minimiza el ancho de banda de la red y los requisitos de recursos del dispositivo mientras intenta garantizar la confiabilidad y cierto grado de garantía de entrega. MQTT se basa directamente en TCP / IP, por lo que utilizamos esos estándares para lograr la mejor seguridad de su clase.

Para ilustrar el valor de la metodología de publicación / suscripción de MQTT sobre la encuesta / respuesta, considere cuánto ancho de banda desperdiciamos con el método anterior. Por ejemplo, anteriormente las empresas preguntaban, cada 30 o 60 minutos, "¿Cuál es la tasa de flujo?" y la respuesta sería "10". Treinta minutos después, "¿Cuál es el caudal?" "10". La pregunta es la misma y la respuesta es la misma, una y otra vez. Con MQTT puede averiguar que el caudal es 10 y luego no volver a escuchar la respuesta a menos que cambie. Las computadoras pueden comunicarse entre sí siempre que quieran enviar datos; informan por excepción.

Reemplazar una red EFM de sondeo / respuesta por una red basada en MQTT ahorra del 80 al 95% del ancho de banda. Eso significa que se pueden rescatar los datos varados.

MQTT también permite múltiples consumidores de datos (Figura 3). Puede publicar los datos desde un dispositivo EFM y múltiples aplicaciones pueden consumirlos, todo al mismo tiempo. MQTT permite una única fuente de verdad para los datos y esos datos son estándar y de código abierto, por lo que cualquiera puede usarlos.

Figura 3: La arquitectura básica de MQTT permite un número ilimitado de clientes a través de un protocolo de publicación / suscripción.

MQTT es el protocolo de mensajería más utilizado para una solución de IoT, pero es hora de que la industria del petróleo y el gas se ponga al día con EFM. No tenemos que demostrar que MQTT se ha convertido en un transporte de IoT dominante: todo el mundo lo usa porque es simple, eficiente y se ejecuta en un espacio reducido. Puede publicar los datos que desee sobre cualquier tema.

Recientemente, creamos una especificación dentro del proyecto Eclipse Tahu llamada Sparkplug que define cómo usar MQTT en un entorno de misión crítica y en tiempo real. Sparkplug define un espacio de nombres de temas MQTT estándar, una carga útil y una gestión del estado de la sesión para aplicaciones industriales al tiempo que cumple con los requisitos de las implementaciones SCADA en tiempo real. Sparkplug es un excelente punto de partida para saber cómo usar MQTT en EFM.

Uno de los desafíos de los métodos EFM antiguos es el manejo de datos atómicos. Los sistemas SCADA pueden manejar variables de proceso individuales, pero varias juntas como un registro les dan problemas. MQTT puede publicar este tipo de datos como registros. MQTT y Sparkplug pueden manejar tanto procesos únicos como registros como un objeto completo con estandarización de datos, datos con marca de tiempo en el origen, datos enviados como un objeto inmutable y la capacidad de almacenar y reenviar.

EFM y MQTT en la práctica

EFM crea grandes cantidades de datos en la fuente. Con MQTT existe una forma estándar de enviar esos datos a toda la empresa, por lo que no importa qué equipo o qué aplicación final hable en qué idioma, es solo un dato, como la temperatura. Todos esos sistemas backend ahora pueden usar la temperatura de forma independiente; como quieran. Los datos EFM se pueden conectar a la nube, a aplicaciones de big data; las posibilidades son infinitas.

Echemos un último vistazo a un cliente que implementó MQTT en su sistema EFM. Su objetivo número uno era obtener más producción de sus pozos. Con MQTT pueden ajustar su pozo una vez por minuto en lugar de una vez por hora, lo que llevó a un aumento en la eficiencia de campo del cinco por ciento, o cientos de millones de dólares. Fueron capaces de eliminar tres sistemas host diferentes, cada uno de los cuales representaba cientos de servidores en rack y se trasladaron a una única fuente de verdad para los datos con un gran agente MQTT, lo que simplificó la infraestructura general de manera significativa.

La denominación errónea en la industria es que la modernización de EFM requiere una gran inversión financiera junto con mucho tiempo y esfuerzo. MQTT es de código abierto y se puede implementar en equipos heredados existentes.

Arlen Nipper aporta más de 42 años de experiencia en la industria SCADA a Cirrus Link como presidente y director de tecnología. Fue uno de los primeros arquitectos de la computación generalizada y el Internet de las cosas y co-inventó MQTT, un protocolo de red de publicación y suscripción que se ha convertido en el estándar de mensajería dominante en IoT. Arlen tiene una licenciatura en Ingeniería Eléctrica y Electrónica (BSEE) de la Universidad Estatal de Oklahoma.

 

Publicado en español el 25 de Octubre del 2021.

Fuente original: https://cirrus-link.com/notes-studies/simply-connect-ignition-and-aws-greengrass-for-machine-learning-2/ 

Compartir

Últimas publicaciones del blog

Your Dynamic Snippet will be displayed here... This message is displayed because you did not provided both a filter and a template to use.


¿Cómo Puede Ayudar Ignition Con El Digital Thread?
El concepto de diseño de Digital Thread encaja perfectamente con las capacidades de la plataforma Ignition.