Walter

Walter

El creciente interés en IIoT ha introducido una gran variedad de tecnologías y estrategias a la hora de abordar todos los datos relacionados con la producción en IIoT. Si bien muchas de estas tecnologías no son nuevas, no son familiares en la industria y requieren explicación. Y esto es claramente lo que ocurre con los términos de computación de borde y computación en niebla. Según Matt Newton, director de Opto 22, “ambos tipos de computación tienen que ver con llevar la inteligencia y las capacidades de procesamiento más cerca de donde se originan los datos”, o sea bombas, motores, sensores, relés, etc. La diferencia clave entre las dos arquitecturas es exactamente dónde se coloca esa inteligencia y poder computacional: 	La computación en niebla coloca la inteligencia a nivel de red de área local de la arquitectura de red, procesando los datos en un nodo de niebla o gateway IoT. 	La computación de borde coloca la inteligencia, el poder de procesamiento y las capacidades de comunicación de un gateway de borde directamente en dispositivos como controladores de automatización programables (PACs). Por su parte, David King, CEO de FogHorn Systems, señala que “muchos en la industria usan los términos de computación en niebla y computación de borde (o procesamiento de borde) de manera intercambiable.”  La computación de borde es en realidad una expresión que precede al término de computación en niebla. A modo de antecedentes, Cisco creó el término computación en niebla años atrás para describir una capa de computación en el borde de la red que permitía que los datos preprocesados pudieran ser transportados de manera rápida y segura a la nube. “Si bien Cisco dominó los aspectos de transporte seguro de la computación en niebla ya desde los primeros días de IoT, muy poco se ha hecho hasta ahora para llevar el procesamiento de datos de la computación en niebla a las aplicaciones de IIoT del mundo real,” comentó David King.  Entrando en más detalles para diferenciar los dos términos, hay que explicar el proceso de transporte de datos de la computación en niebla. Según Newton, los datos provenientes del programa del sistema de control son enviados a un servidor OPC o gateway de protocolo, que convierte los datos en un protocolo que entienden los sistemas Internet, tales como MQTT o HTTP.  Luego, los datos son enviados a otro sistema, por ejemplo un nodo de niebla o gateway IIoT en la LAN, que recolecta los datos y realiza el procesamiento y análisis de mayor nivel. Este sistema filtra, analiza, procesa e incluso almacena los datos para su transmisión a la nube o WAN en una fecha posterior. La arquitectura de la computación en niebla se basa en numerosos enlaces en una cadena de comunicación que mueve los datos desde el mundo físico de activos al mundo digital de IT. Cada uno de estos enlaces es un potencial punto de falla. De acuerdo a Newton, la computación de borde “simplifica esta cadena de comunicación y reduce el número de puntos potenciales de falla a la hora de cablear activos físicos, tales como bombas y motores, en un PAC inteligente para recolectar, analizar y procesar datos provenientes de los activos físicos mientras corre el programa del sistema de control. Los PACs utilizan luego las capacidades de la computación de borde para definir qué datos deben ser almacenados localmente o enviados a la nube para un posterior análisis. En la computación de borde, la inteligencia es llevada literalmente al borde de la red, donde los activos físicos están conectados juntos por primera vez y donde se originan los datos de IoT.” Como su nombre lo sugiere, FogHorn Systems es un defensor de la computación en niebla, pero con una nueva vuelta de tuerca en cuanto a proceso. King señala que están mejorando el concepto de computación en niebla teniendo en cuenta que “la computación de borde no es escalable y no permite ver a través de múltiples máquinas o procesos. El nuevo concepto es acercarse lo más que se pueda a la fuente sin quedar atrapados en el nivel de la máquina individual.” La tecnología de FogHorn va más allá de filtrar los datos y normalizar los datos, y no usa una lógica de motor de reglas básicas como conector local para la analítica basada en la nube. Aplica una nueva capa inteligente en o cerca de la fuente de los datos en un gateway de niebla para filtrar y normalizar los datos antes de pasarlos a la nube.

 

El creciente interés en IIoT ha introducido una gran variedad de tecnologías y estrategias a la hora de abordar todos los datos relacionados con la producción en IIoT. Si bien muchas de estas tecnologías no son nuevas, no son familiares en la industria y requieren explicación. Y esto es claramente lo que ocurre con los términos de computación de borde y computación en niebla.

Según Matt Newton, director de Opto 22, “ambos tipos de computación tienen que ver con llevar la inteligencia y las capacidades de procesamiento más cerca de donde se originan los datos”, o sea bombas, motores, sensores, relés, etc. La diferencia clave entre las dos arquitecturas es exactamente dónde se coloca esa inteligencia y poder computacional:

  • La computación en niebla coloca la inteligencia a nivel de red de área local de la arquitectura de red, procesando los datos en un nodo de niebla o gateway IoT.
  • La computación de borde coloca la inteligencia, el poder de procesamiento y las capacidades de comunicación de un gateway de borde directamente en dispositivos como controladores de automatización programables (PACs).

Por su parte, David King, CEO de FogHorn Systems, señala que “muchos en la industria usan los términos de computación en niebla y computación de borde (o procesamiento de borde) de manera intercambiable.

La computación de borde es en realidad una expresión que precede al término de computación en niebla. A modo de antecedentes, Cisco creó el término computación en niebla años atrás para describir una capa de computación en el borde de la red que permitía que los datos preprocesados pudieran ser transportados de manera rápida y segura a la nube. “Si bien Cisco dominó los aspectos de transporte seguro de la computación en niebla ya desde los primeros días de IoT, muy poco se ha hecho hasta ahora para llevar el procesamiento de datos de la computación en niebla a las aplicaciones de IIoT del mundo real,” comentó David King.

Entrando en más detalles para diferenciar los dos términos, hay que explicar el proceso de transporte de datos de la computación en niebla. Según Newton, los datos provenientes del programa del sistema de control son enviados a un servidor OPC o gateway de protocolo, que convierte los datos en un protocolo que entienden los sistemas Internet, tales como MQTT o HTTP.

Luego, los datos son enviados a otro sistema, por ejemplo un nodo de niebla o gateway IIoT en la LAN, que recolecta los datos y realiza el procesamiento y análisis de mayor nivel. Este sistema filtra, analiza, procesa e incluso almacena los datos para su transmisión a la nube o WAN en una fecha posterior. La arquitectura de la computación en niebla se basa en numerosos enlaces en una cadena de comunicación que mueve los datos desde el mundo físico de activos al mundo digital de IT. Cada uno de estos enlaces es un potencial punto de falla.

De acuerdo a Newton, la computación de borde “simplifica esta cadena de comunicación y reduce el número de puntos potenciales de falla a la hora de cablear activos físicos, tales como bombas y motores, en un PAC inteligente para recolectar, analizar y procesar datos provenientes de los activos físicos mientras corre el programa del sistema de control. Los PACs utilizan luego las capacidades de la computación de borde para definir qué datos deben ser almacenados localmente o enviados a la nube para un posterior análisis. En la computación de borde, la inteligencia es llevada literalmente al borde de la red, donde los activos físicos están conectados juntos por primera vez y donde se originan los datos de IoT.

Como su nombre lo sugiere, FogHorn Systems es un defensor de la computación en niebla, pero con una nueva vuelta de tuerca en cuanto a proceso. King señala que están mejorando el concepto de computación en niebla teniendo en cuenta que “la computación de borde no es escalable y no permite ver a través de múltiples máquinas o procesos. El nuevo concepto es acercarse lo más que se pueda a la fuente sin quedar atrapados en el nivel de la máquina individual.

La tecnología de FogHorn va más allá de filtrar los datos y normalizar los datos, y no usa una lógica de motor de reglas básicas como conector local para la analítica basada en la nube. Aplica una nueva capa inteligente en o cerca de la fuente de los datos en un gateway de niebla para filtrar y normalizar los datos antes de pasarlos a la nube.

Los dispositivos USB son una amenaza para las instalaciones industriales

 

Una reciente investigación realizada por Honeywell muestra que los dispositivos USB extraíbles, tales como unidades de memoria flash, representan una amenaza de ciberseguridad importante e intencional para una amplia gama de redes de control de procesos a nivel industrial.

Los datos derivados del uso de la tecnología de Honeywell para escanear y controlar dispositivos USB en 50 plantas de usuarios mostraron que en casi la mitad (44%) se pudo detectar y bloquear al menos un archivo con problema de seguridad. También reveló que el 26% de las amenazas detectadas eran capaces de generar un trastorno importante al impedir que los operadores tuvieran visibilidad o control de sus operaciones.

Las amenazas apuntaban a una gran variedad de sitios industriales, tales como refinerías, plantas químicas y fabricantes de pulpa y papel de todo el mundo, y las amenazas en sí mismas eran severas. Casi 1 de cada 6 apuntaba a sistemas de control industrial o dispositivos IoT.

"Los datos mostraron amenazas mucho más serias que lo esperado y, en conjunto, los resultados indican que algunas de estas amenazas fueron dirigidas e intencionales", comentó Eric Knapp, director de Honeywell Industrial Cyber Security. "Esta investigación confirma lo que se sospechaba durante años: las amenazas USB son reales para los operadores industriales. Lo que sorprende es el alcance y la severidad de las amenazas, muchas de las cuales pueden llevar a situaciones serias y peligrosas en sitios que manejan procesos industriales".

La investigación examinó los datos recolectados de la tecnología Secure Media Exchange (SMX) de Honeywell, diseñada específicamente para escanear y controlar medios extraíbles, incluyendo drives USB. Entre las amenazas detectadas se encontraban problemas bien conocidos y de alto perfil, tales como TRITON y Mirai, además de variantes de Stuxnet, un tipo de ataque previamente aprovechado por estados para interrumpir operaciones industriales. En pruebas comparativas, hasta el 11% de las amenazas descubiertas no pudieron ser detectadas de manera confiable por una tecnología anti-malware más tradicional.

"Los clientes ya saben que estas amenazas existen, pero muchos creen que no los va a tocar", dijo Knapp. "Pero estos datos muestran lo contrario y subrayan la necesidad de sistemas avanzados para detectar las amenazas".

La investigación recomienda que los operadores combinen capacitación de personal, cambios en el proceso y soluciones técnicas para bajar el riesgo de amenazas de USB en sus instalaciones industriales.

El estándar API 2350 ofrece una guía específica acerca de cómo prevenir el sobrellenado en tanques de almacenamiento de hidrocarburos. El estándar ya tiene sus años; la cuarta edición fue publicada en 2012 y este año se viene la quinta edición.

El estándar API 2350, destinado a los operadores de tanques, describe las mejores prácticas para prevenir eventos de sobrellenado en tanques de almacenamiento de hidrocarburos. El almacenamiento de una gran cantidad de combustibles, petróleo crudo y otros líquidos peligrosos en tanques suele generar un riesgo y un peligro potencial en una instalación en caso de no ser operados, mantenidos y diseñados correctamente.

Lo que hace que el sobrellenado de un tanque sea particularmente peligroso está en que se puede generar una nube de vapor mortal, que puede desplazarse mucho más allá de una contención secundaria para terminar en una detonación y condiciones peligrosas para las comunidades cercanas. Un ejemplo que repercutió mucho en la API 2350 fue el incendio de Buncefield en 2005.

Es importante señalar al respecto que API 2350 no es una regulación para cumplir, sino un estándar recomendado. Sin embargo, dentro de este contexto, las organizaciones que adopten los procesos descritos en API 2350 se verán beneficiadas por la posibilidad de controlar los peligros, lo que lleva a una menor exposición a riesgos, incidentes y accidentes, y lograr menores primas de seguro y gastos operativos.

Las nuevas prácticas recomendadas por API también pueden mejorar la operación normal y la eficiencia. La mejora en las operaciones es el resultado de procedimientos específicos, claros y procesables que son comprensibles y accesibles para el personal de operaciones. Eliminar la incertidumbre en las instalaciones reduce variaciones en las operaciones, mejorando el proceso. En cuanto a la eficiencia, aumenta ya que la implementación de API 2350 conlleva muchas veces una expansión del espacio utilizable del tanque.

 

Tanques de almacenamiento de hidrocarburos: Se vienen las actualizaciones de API 2350
El incendio en una instalación causado por el sobrellenado de un tanque de almacenamiento puede llevar a condiciones peligrosas. (Gentileza de Endress+Hauser)

 

Recomendaciones que ofrece API 2350

El estándar API 2350 contiene una serie de prácticas y procedimientos recomendados, que incluyen:

  • Implementar un proceso de prevención de sobrellenado (OPP según sus siglas en inglés);
  • Aplicar prácticas de mantenimiento preventivo en el sistema y equipos de prevención de sobrellenado;
  • Desarrollar procedimientos escritos para operar en condiciones normales, anormales, de arranque y de parada, como así también comunicaciones entre abastecimiento y empresas receptoras;
  • Definir parámetros operativos iniciales para cada tanque, que cubre categorías de equipos, niveles en cuestión, tiempos de respuesta y procedimientos de alarma;
  • Implementar y mantener un sistema de evaluación de riesgos.

 

Preparado en base a un documento de Dean Mallon, de Endress+Hauser.

Gestión del desempeño de activos e IIoT

 

A no dudarlo: IIoT jugará un rol clave a la hora de implementar una APM (gestión del desempeño de activos) avanzada.

    Al respecto, todos sabemos que es necesario medir el estado de los activos para poder maximizar la eficiencia operativa de los mismos (‘cosas’ para IIoT). Por ejemplo, son innumerables los activos en una planta petrolera, tales como miles de bombas y quizás 100 km de cañerías en total. Es difícil detectar la corrosión en todas estas líneas.

Para prevenir paradas y accidentes de planta inesperados, es necesario monitorear muchas cosas, tales como vibración de las instalaciones, fugas de líquidos y gases, temperaturas anormales y un ruido inusual. Además, aun cuando se puedan medir muchos de estos inconvenientes, los datos no son transmitidos más allá de los paneles de control e indicadores en el campo a la sala de control central.

Para obtener datos valiosos de medición, los operadores humanos patrullan distintas ubicaciones en el campo todos los días, incluso ubicaciones en altura y otros lugares de difícil acceso, y físicamente deben tocar instalaciones para chequear temperatura y vibración, escuchar ruido o detectar alguna anomalía. Gracias a tan meticulosos esfuerzos, las plantas se mantienen libres de accidentes y operan en forma continuada.

Mientras tanto, la evolución de la tecnología de sensado ha hecho posible la lectura de datos que normalmente no se podía realizar o sólo eran estimados indirectamente. Hoy en día, en una planta se pueden instalar nuevos sensores compactos con comunicación wireless y baterías de larga vida. En consecuencia, ya es posible recibir señales desde miles de sensores remotos durante largos periodos de tiempo.

Activos equipados con sensores muestran su estado en la red. El tiempo y la distancia dejaron de ser restricciones; el estado de los activos puede ser monitoreado en todo momento desde múltiples oficinas dondequiera que estén ubicadas. Salvo por el costo inicial de los sensores, no hay otros gastos; los datos son transmitidos casi sin costo y no hay necesidad de cables, racks y el trabajo de instalarlos. Además, los errores humanos y las diferencias entre personas a la hora de leer valores quedan eliminados. Sensores de alta performance podrán detectar luz, sonido, olores, vibración durante largos periodos, distorsión y medir otros objetos que no pueden ser sensados por los operadores humanos. Estos datos son registrados digitalmente y acumulados para su análisis y mejora en el futuro.

El valor que aporta APM queda definido por dos aspectos:

  • Productos que incorporan una tecnología avanzada de sensado;
  • La mejora operativa que se obtiene analizando la información acerca de activos, producción y mantenimiento.

En particular, el segundo punto es crítico para empresas con activos ya que esta mejora aumenta su competitividad de costos. Aun cuando también sea una ventaja que la información pueda ser almacenada en servidores o en la nube y pueda ser transmitida rápidamente a lugares distantes, estos aspectos no son tan críticos.

Cabe señalar que la importancia de las mejoras y el valor agregado que ofrece APM no es proporcional al costo involucrado salvo en lo que hace a sensores y otro hardware. Piense en un proyecto de construcción: sus costos quedan determinados por las cantidades de hormigón, acero y otros materiales, duración de la construcción, etc., y todos ellos son proporcionales al tamaño del edificio a construir. En cambio, el valor agregado que aporta APM no necesariamente es proporcional al costo. Las cantidades y clases de datos y su distancia de transmisión no inciden en el costo. La importancia del valor agregado queda definida por cómo se analizan estos datos, por cómo se identifican las relaciones con la tasa de falla y por cómo se usa esta información para mejorar el proceso de manufactura y el mantenimiento. El gasto adicional (costo marginal) para aumentar el valor agregado se aproxima a cero.

Un sistema bien diseñado permite que los sensores detecten síntomas y que sean analizados por el algoritmo para compararlos con los datos pasados acumulados en el sistema de gestión de mantenimiento. Si es necesario, el sistema alerta al personal de mantenimiento y propone una acción adecuada mientras muestra los documentos pertinentes. El sistema también notifica al sistema MES y al sistema de control acerca de cualquier anomalía y obliga a estos sistemas a tomar la acción que corresponde para la producción. De acuerdo al estado de los procesos, el sistema muestra información de respaldo para los operadores. Mientras tanto, se van acumulando registros de mantenimiento en el sistema de gestión de mantenimiento de los equipos para su análisis en el futuro. Se espera que estos sistemas puedan cooperar de manera más eficaz y compartir información entre ellos.

 

Preparado en base a una presentación de Junji Yamamoto, de Yokogawa.

Utilización eficiente de datos sin usar
Endress+Hauser: Utilización inteligente de datos e información provenientes del nivel de campo.

 

En la próxima Hannover Messe 2019, Endress+Hauser mostrará en su stand la utilización inteligente de datos e información obtenidos de dispositivos de campo y la manera en que se puede liberar ese enorme potencial oculto en una planta. La base de esta estrategia es la información de diagnóstico generada por Heartbeat Technology, una gran variedad de interface digitales y módulos de conectividad,  y el ecosistema Netilion IIoT.

 

Netilion: Ecosistema IIoT basado en la nube

Todos los usuarios están interesados en temas como mantenimiento predictivo y evitar paradas de sistema no planificadas. Endress+Hauser ofrece ahora soluciones que usan el potencial oculto en sus dispositivos de campo. Como los datos ya existen, las aplicaciones de Netilion permiten a los usuarios aprovecharlos. Con el ecosistema Netilion basado en la nube, es posible implementar aplicaciones inteligentes y conectadas para IIoT.

 

Heartbeat Technology: Sentir constantemente el pulso

Endress+Hauser ofrece una amplia gama de instrumentos equipados con Heartbeat, una tecnología que ofrece un alto nivel de disponibilidad de sistema con un mínimo esfuerzo. Esta tecnología integrada entrega notificaciones concisas y estandarizadas de diagnóstico y datos de monitoreo que permiten a los usuarios atender y mantener sus sistemas de manera precisa cuando sea necesario. Junto con las aplicaciones de Netilion, estos datos facilitan el mantenimiento predictivo. La información también aporta una indicación de la confiabilidad operativa y seguridad del proceso. Puesto que los instrumentos monitorean automáticamente sus condiciones, se pueden reducir los ciclos de inspección manual.

 

Utilización eficiente de datos sin usar
El ecosistema Netilion basado en la nube respalda a los usuarios con aplicaciones inteligentes y conectadas.

 

Otras novedades

El nuevo Liquiphant FTL51B es un robusto switch de nivel puntual para todos los líquidos que viene ahora con Heartbeat Technology integrada para pruebas documentadas sin necesidad de remover el instrumento o interrumpir el proceso.

Otro producto nuevo con Heartbeat Technology es Gammapilot FMG50, un transmisor de nivel radiométrico que puede ser instalado allí donde otros principios de medición no pueden resolver la aplicación.

Otras novedades son el caudalímetro Proline 300/500 y un nuevo sensor de flujo Promass A para medir pequeños caudales, que también está disponible con tecnología bifilar.

¿Sus activos críticos se desempeñan de la mejor manera? ¿Una parada no planificada está afectando los resultados de la empresa? ¿Su organización apunta a lograr mejoras en la eficiencia de activos y procesos? Ya no más reaccionar. Comience a predecir. Reexamine los métodos tradicionales de gestión del desempeño de activos.

Todos nosotros reconocemos que la disponibilidad y el desempeño de activos, contrapuestos con los costos de mantenimiento y una parada planificada, son factores clave en pos de una mejor productividad. El desafío real en estos casos está en conocer cuál es el balance correcto.

Comprender la estrategia es el primer paso. Tener una estrategia de gestión del desempeño de activos (APM según sus siglas en inglés) es la dirección correcta cuando se la compara con el método tradicional reactivo de ‘dejar que funcione hasta que falle’.

La APM tradicional se ha enfocado en el riesgo de los activos, la confiabilidad y reducir el costo de mantenimiento, principalmente en base a métodos convencionales de monitoreo de activos. La implementación de una APM tradicional es compleja y costosa y, en consecuencia, es implementada sólo en activos de mucho capital. Asimismo, mantener un tal sistema actualizado y seguro requiere una inversión importante en IT y en experticia operativa y con frecuencia involucra múltiples proveedores. Además, a pesar de los datos valiosos generados por estos sistemas, suelen estar desconectados y no permiten a los gerentes de planta tomar decisiones de mayor confianza acerca de cómo operar.

 

Descubrir el poder de los activos conectados

 

Una APM más inteligente

Si bien la mayoría de las plantas operan de manera eficiente, hay oportunidades de mejora, especialmente allí donde la producción implica muchos activos o tiene una capacidad restringida, o cuando las mejoras marginales no son una opción. Para evaluar la situación, conviene plantearse algunas preguntas:

  • ¿Cuán fácil es comprender el impacto económico de un desempeño subóptimo de los equipos?
  • ¿Es mejor reducir la producción para extender la vida los equipos críticos? ¿O se deben exigir los equipos para maximizar las demandas de producción actuales?
  • ¿Se puede reducir una excesiva inspección de ciertas partes de los equipos para ahorrar en el presupuesto de mantenimiento?
  • ¿Los ahorros potenciales en el costo de mantenimiento pueden quedar anulados por las pérdidas (estadísticas) originadas por una posible parada no planificada?

La posibilidad de tener una conectividad segura en una gama más amplia de activos, monitorear de manera continua tanto la salud de los activos como el desempeño del proceso, y combinar analítica predictiva con experticia industrial, se traduce en una APM más inteligente y asegura una toma de decisiones con mayor confianza. Una estrategia APM digitalmente transformada y conectada mejora la certeza de la producción y los resultados al eliminar silos y cerrar efectivamente el lazo entre operaciones y mantenimiento.

Aumentar el tiempo de operación requiere llevar y reunir datos de activos, datos de proceso y ajustes operacionales en un entorno seguro y conectado. En este esquema, los expertos en activos y proceso pueden usar analítica para encontrar los mejores caminos a fin de eliminar una parada no planificada y optimizar el mantenimiento de los equipos.

A la hora de evaluar la situación, es importante tener en cuenta que proceso y equipos son inseparables. Las fallas de los equipos no pueden ser completamente analizadas, pronosticadas o reducidas con tan sólo observar los datos de gestión de activos. La confiabilidad de un activo depende de cómo está siendo operado un proceso y si ese activo está siendo óptimamente mantenido. Después de todo, las fallas de operación y de equipos a causa de mantenimiento se encuentran en la mayoría de las paradas no planificadas.

La mejor performance y eficacia de los equipos son el resultado de combinar conocimiento de proceso con experticia en equipos dentro de un ecosistema de software colaborativo y conectado.

 

Conceptos básicos de una estrategia con activos conectados

Son varios los factores a tener en cuenta a la hora de planificar una iniciativa de gestión del desempeño con activos conectados:

  • Comprender que APM está atravesando rápidamente por una transformación digital. Una APM tradicional necesita proyectos con una gran inversión de capital, muchas interfaces artesanales y conjuntos duplicados de datos. Muchas veces viene acompañada por una administración de sistema compleja, actualizaciones y mucha capacitación del usuario final. Esta combinación puede ser un freno para mejoras y presionar los recursos de una planta.
  • Aprovechar la simplicidad y velocidad de un software conectado trabajando con un proveedor que tenga una profunda experticia a fin de acelerar la implementación de la APM. El tiempo de implementación puede ser medido en días o semanas en lugar de meses o años. Hay que pensar en un enfoque que mezcle conectividad segura, analítica avanzada y configuración automatizada de software para tener una solución con la que sea fácil de convivir ya desde sus comienzos.
  • La ciberseguridad no es opcional. Las amenazas de ciberseguridad están por doquier y siempre crecientes. No puede haber excepciones: cada iniciativa de gestión de desempeño, operación y automatización de cada activo debe involucrar métodos amplios y vigilantes de seguridad.
  • Las personas son la inversión más importante. El mejor software APM tan sólo es una guía para lo que hay hacer. Las mejoras no ocurren sin supervisores, ingenieros y operadores entrenados para mantener y operar los equipos. La próxima generación de profesionales en la industria de procesos gestionarán las plantas de manera muy diferente, aprovechando el software conectado de nuevas maneras a fin de mejorar las operaciones mucho más allá de lo que se podía lograr hasta ahora.

 

Conclusión

Es posible evitar fallas de activos críticos y paradas no planificadas, además de mejorar los resultados de la empresa, implementando una estrategia de gestión de desempeño de activos conectados. Con las tecnologías apropiadas, el personal de planta podrá colaborar de manera más eficaz y gestionar proactivamente la producción. Desplegar una iniciativa APM inteligente y conectada simplifica la implementación, elimina silos y cierra efectivamente el lazo para optimizar operaciones y mantenimiento.

 

Preparado en base a una presentación de Dan O’Brien, director de Honeywell Connected Plant.

Computación de borde: Lo mejor de dos mundos

 

La computación de borde (edge computing) es una expresión bastante de moda. Si se le pregunta a cualquier empresa de informática si hacen computación de borde, la respuesta más probable es que sí. La expresión está tan sobreutilizada que, en muchos casos, casi ha perdido su significado, simplemente queriendo decir: “Sí, tenemos una PC industrial por algún lado, con un programa en ejecución.” Pero esto, en realidad, no refleja la esencia de la computación de borde y, sin duda, no alcanza a cubrir todo su potencial innovador, fundamentalmente en aplicaciones industriales.

 

La era de la informática en la nube

La historia de la informática muestra varias olas de procesamiento de datos local versus centralizado. En los últimos años, se ha visto una fuerte tendencia hacia la informática en la nube: la gestión de datos y la informática se están trasladando a grandes áreas centralizadas de servidores, mientras las computadoras personales se limitan a albergar un buscador de red.

Las ventajas de la gestión de datos en la nube resultan evidentes:

  • Actualizaciones de software fáciles y rápidas, ya que se pueden gestionar desde un lugar de origen centralizado;
  • Una visión global e integrada de todos los flujos de tareas y equipos conectados a la nube, lo que permite tomar decisiones tanto a nivel global como local;
  • Un lugar centralizado con todos los datos para ulteriores optimizaciones.

 

Limitaciones de la gestión de datos

en la nube

Pero este nuevo futuro brillante también tiene sus desventajas. Con la transición general a IoT y la maquinaria y la logística conectadas a la nube, nos esperan nuevos desafíos. Hoy en día, cuando las cosas reales, tales como automóviles, edificios y turbinas, vienen equipados con un mellizo digital, se recolectan cada vez más datos para procesar en aplicaciones de gestión de datos en la nube.

Por ejemplo, si las vibraciones en una máquina se salen de control, pueden fácilmente causar una reacción en cadena, capaz de inhabilitar toda la línea de producción. En consecuencia, los sistemas de control modernos vienen con una creciente cantidad de sensores colocados en las partes clave de la máquina, que se encargan de detectar estas vibraciones y enviar sus datos al sistema operativo, en la nube, para su análisis continuo y concretar su mantenimiento predictivo. Imagínese todos estos pequeños sensores produciendo datos en un entorno de producción industrial: la carga de datos es enorme.

  Y es allí donde aparece uno de los principales desafíos de la gestión de datos en la nube. Si se trabaja con procesamiento de datos en la nube, es probable que surjan varios inconvenientes:

  • Limitaciones físicas de la transferencia de datos (¡todavía los bits y bytes no pueden viajar más rápido que la luz!);
  • Dependencia de la disponibilidad de la red (cuando se cae la red, el control y la optimización desde la nube también se caen);
  • Carga de datos (aun a alta velocidad, una transferencia de datos de esta magnitud es demasiado lenta);
  • Privacidad de los datos (hay datos que las empresas industriales no se sienten cómodas de compartir en la nube);
  • Ciberseguridad (la transferencia de datos dentro de los sistemas que se encuentran en la nube siempre ofrece una vulnerabilidad al robo, por lo que la transferencia de datos en sistemas que operan en la nube generalmente está confinada a subir datos, dado que la descarga es aún más sensible a los ciberataques).

El manejo de una carga considerable de datos es más sencillo cuando los datos se procesan a nivel local. ¿Estamos listos para un revival? ¿La ola de la historia de la informática está dando la vuelta hacia el procesamiento de datos local? Sí y no. Y es allí donde hace su entrada la computación de borde.

 

Computación de borde

La  computación de borde no es algo nuevo. Los actores más importantes en informática, tales como Cisco, la han utilizado durante años junto con su hermana en niebla (fog). La verdadera innovación tiene que ver con la más reciente integración con los procesos de producción industrial y su optimización dentro de los sistemas que operan en la nube.

Las aplicaciones de borde, tales como Analyze MyWorkpiece, no sólo ofrecen la posibilidad de recolectar y analizar los datos cerca de donde se originan dentro del proceso de producción, sino que, por ejemplo en Siemens, también se integran con MindSphere, un sistema operativo de IoT que se encuentra en la nube. En la computación de borde, el procesamiento de datos no es exclusivo del núcleo de la nube, sino que, fundamentalmente, ocurre en la periferia, el borde de Internet, donde ésta se pone en contacto con el mundo físico.

La integración de la computación de borde en las nubes industriales permite aprovechar los beneficios de los sistemas que se encuentran en la nube, tales como actualizaciones de software rápidas y fáciles, mientras que, a la vez, aprovecha las ventajas del procesamiento de datos local, tales como seguridad de datos, reacciones rápidas de las aplicaciones y el entorno de control dentro de un proceso de producción industrial.

 

¿Por qué la computación de borde industrial es la solución?

Hay mucho entusiasmo por la computación de borde industrial, aun cuando surjan algunas inquietudes:

  • Los riesgos de la implementación de la digitalización;
  • La adquisición de una solución de nicho con poca escalabilidad;
  • La inversión en un prototipo que no funcione para todas las máquinas.

  Pero con las aplicaciones de borde industriales resulta sencillo despejar estas inquietudes. Ofrecen soluciones totalmente integradas, implementables y económicas en temas muy importantes, tales como mantener la privacidad y hacer frente a una gran carga de datos, lograr las mejoras prometidas por la digitalización y aprovechar a la vez la gestión de los datos en la nube.

 

Preparado en base a una presentación de Michal Skubacz, de Siemens.

Monitoreo versus control: con caudalímetros wireless

 

Las técnicas de caudalimetría siguen creciendo y evolucionando de la mano de nuevos métodos, tales como ultrasónico multihaz, magnético y Coriolis, en detrimento de las tecnologías más tradicionales, tales como orificio, vertedero y otras técnicas basadas en presión diferencial (DP).

El creciente uso de estas nuevas tecnologías se debe en parte a la mayor capacidad de microprocesadores y sensores para realizar mediciones imposibles de concretar sin las mejoras obtenidas en estas áreas. Otra razón de su adopción es que, en la mayoría de los casos, ofrecen mayores niveles de exactitud y rangeability que las tecnologías DP. Pero la mayoría de estas técnicas de medición de caudal tienden a requerir más energía que los caudalímetros DP, razón por la que no resultan adecuados para su implementación como dispositivos wireless.

Un tema importante a la hora de usar wireless en caudalimetría es la dinámica del propio proceso. La mayoría de los lazos de caudal, especialmente para líquidos (fluidos incompresibles), tiene tiempos de respuesta de proceso muy cortos, muchas veces en el orden de los segundos, a diferencia de temperatura y nivel, que tienden a ser mucho más largos (minutos). En consecuencia, para usar un sensor wireless en control de caudal, se necesita una rápida tasa de actualización para el transmisor como mínimo, lo cual, por supuesto, lleva a una corta vida de la batería y hace que se vea mejor la economía del cable.

Una manera de abordar el tema del tiempo de respuesta es incrementar la capacidad del dispositivo de caudal agregando la posibilidad de desempeñarse como controlador de caudal de un solo lazo o autocontenido. De esta forma, el lazo de control sólo requiere la transmisión de la salida al elemento de control final y HMI remota cuando se requiere un tal cambio, que no es probable que ocurra en cada ciclo de sensado o actualización (suponiendo que el sistema de control puede aceptar cierto grado de banda muerta en la señal).

Si la banda muerta no es aceptable, tener el transmisor actualizando el sistema de control con fines de historización y medición cada ciclo y enviar la salida directamente al dispositivo según necesidad es una situación mucho más compleja que gestionar las distintas tasas de actualización desde un dispositivo en función del tipo de datos.

Con todas estas características, el transmisor se acerca a la visión del foro Open Processs Automation (OPA) de un nodo de control de dispositivos (DCN) y está más cerca de un controlador de campo SCADA RTU que está siendo monitoreado y controlado (esto es, cambiar el setpoint) en forma remota desde una estación de control central. Normalmente, el SCADA incluye wireless pero, una vez más, con ciclos de actualización más largos e inteligencia en el campo.

La aparentemente simple alternativa de monitoreo versus control o transferencia custodiada afecta no sólo el tipo de sensor requerido, sino también de qué manera interactúa con el sistema de control y los demás dispositivos dentro del sistema de control.

Si bien esto es cierto incluso más allá de la medición de caudal, el impacto es mucho más pronunciado en los lazos rápidos de control, como es el de caudal, sin importar la manera en que se puedan superar los principios básicos y la razón por la que se instala el sistema.

 

Preparado por Ian Verhappen, gerente de proyectos de automatización en CIMA+.

Combo controlador SIMATIC y PC

Los integradores e ingenieros de automatización a menudo se enfrentan con tener que hacer una aplicación en el controlador /PLC y otra en la PC. Para los operadores, alternar de una pantalla a la otra no sólo consume tiempo valioso, sino que, además, puede ser un inconveniente para sus eficiencias. En algunos casos, hay que quitarse las prendas de protección como guantes (y después ponérselos de nuevo) debido a esta alternancia.

Tener todo en un solo dispositivo ofrece muchas ventajas para los que trabajan en la automatización de fábricas. Las tareas complejas de automatización que incluyen muchas aplicaciones ahora se pueden implementar en una sola plataforma. Además, las funciones y soluciones complejas para tareas de automatización ya están disponibles en lenguajes de nivel superior o ya están creadas en esos lenguajes a partir de un trabajo científico o académico.

Es por estos motivos que Siemens decidió integrar la funcionalidad de una PC al diseño del controlador SIMATIC. Los programas en lenguajes de nivel superior se comunican con el PLC a través de interfaces definidas en la recientemente lanzada plataforma multifunción CPU 1518(F)-4 PN/DP MFP. Además de los bloques estándar STEP 7 utilizados con SIMATIC, esta CPU también puede ejecutar funciones (bloques) y aplicaciones programadas en C o C++, como normalmente utilizan las aplicaciones para PC. Esto incluye las aplicaciones basadas en modelos y bases de datos.

Esta solución innovadora ofrece a los usuarios la opción de ejecutar un código C/C++ de forma sincronizada con el ciclo de la CPU (a través de la biblioteca de funciones de la CPU). Además, esta plataforma multifunción puede ejecutar aplicaciones C/C++ como aplicaciones independientes en paralelo al tiempo de ejecución de la CPU.

Los intercambios de datos entre el tiempo de ejecución C/C++ y el tiempo de ejecución de la CPU se pueden utilizar para disparar respuestas del otro lado o para brindar la información necesaria al TIA Portal.

La plataforma multifunción MFP se desarrolla a partir del controlador modular superior SIMATIC CPU 1518-4 PN/DP (F). La nueva MFP, con firmware versión V2.5, se puede utilizar con el TIA Portal V15 o superior. La MFP posee suficiente capacidad de procesamiento para fusionar ahora fácilmente aplicaciones separadas anteriormente en una plataforma común. A la vez, la plataforma multifunción cubre los exigentes requerimientos del S7-1500 en términos de facilidad de mantenimiento y robustez.

Al fusionar las aplicaciones con lenguaje de programación de alto nivel en C/C++ y las aplicaciones de SIMATIC PLC en una sola pieza de hardware, se reduce la instalación y, a la vez, se consigue la robustez ya comprobada de un SIMATIC S7-1500. Al mismo tiempo, las aplicaciones independientes del controlador, tales como convertidores de protocolo, aplicaciones de bases de datos y otras, se pueden crear en C/C++, lo que simplifica la creación o reutilización de aplicaciones de lenguaje de alto nivel a medida.

Asimismo, es posible adoptar directamente funciones complejas luego de la generación de un código utilizando herramientas de diseño basadas en modelos como Simulink de MathWorks.

Las actualizaciones regulares del firmware garantizan los mayores estándares de seguridad, permitiéndoles a los usuarios enfocarse en la implementación de sus requisitos de automatización.

Tres interfaces PROFINET, una interface PROFIBUS DP, la capacidad de compartir dispositivos entre hasta cuatro controladores, redundancia de medios y una comunicación Ethernet abierta son algunas de las funciones adicionales incorporadas.

La función de seguridad integrada incluye:

  • Protección del know-how por medio de contraseñas contra la lectura no autorizada o la modificación de los bloques de programa.
  • Protección contra copias para evitar la reproducción no autorizada de los bloques de programa.
  • Capacidad para asignar los derechos de acceso al controlador a diferentes grupos de usuarios.

 

Preparado por el Ing. Andrés Gorenberg, de Siemens.

Para más información, visite www.siemens.com/mfp

Cuatro recomendaciones a la hora de monitorear activos

 

El monitoreo y los diagnósticos son factores críticos en los programas de gestión de activos. A continuación se detallan cuatro recomendaciones para implementar sistemas de monitoreo más eficaces.

 

1|Implementación

Cuando se deben conectar varios equipos a un sistema de monitoreo remoto, lo recomendable es comenzar por conectar unos pocos estratégicos y hacerlos funcionar varios días para comprender los problemas que pudieran surgir en el entorno o con la conectividad, expectativas del usuario, patrones de uso, etc.

Una vez obtenida esta realimentación y afinado el sistema, el escalado ya no es difícil. En cambio, si hubiera arrancado directamente con todos los activos, se multiplicarían los problemas.

 

2|Identificar las propiedades de los diagnósticos

Se acabaron los días cuando la automatización incluía sistemas de diagnóstico, que sólo utilizaban código binario disparado por E/Ss. Los entornos de manufactura de hoy en día exigen monitoreo de estado y diagnósticos en tiempo real.

Los diagnósticos de prueba y error ya no son suficientes para identificar un problema a la hora de resolver inconvenientes que detienen la producción.

La rápida evolución de la tecnología hace casi imposible mantenerse actualizado con todas las opciones disponibles hoy en día. La tecnología permite ahora el monitoreo en tiempo real del estado de una máquina, condiciones de error, temperatura de los componentes vitales, velocidad, consumo de corriente y una gran cantidad de otros datos que se pueden obtener a través de una HMI u otro dispositivo.

Con tanta información potencialmente disponible, es necesario que los diseñadores asistan a los usuarios finales para determinar exactamente qué información es crítica para su operación y la mejor manera de presentar la información. La interacción con el usuario final es vital. Se debe tener una comprensión cabal de los criterios de performance del usuario, de los requerimientos en cuanto a diagnósticos y de los procedimientos de resolución de problemas.

El tiempo que se invierte en obtener esta información es la base para el resto del proyecto.

3|Sistema de monitoreo

Si la tarea es recolectar datos de máquinas que utilizan PLCs, se debe incluir algún nivel de monitoreo del sistema. Puede ser tan simple como un test del ping al PLC o un toggle de bits en caso de que la aplicación trabaje a nivel de bits.

De cualquier forma, se debe monitorear el enlace de comunicaciones y crear alertas en caso de fallas. La alerta puede ser algo sencillo, por ejemplo, como una alarma de máquina, o el envío de un email de alerta a IT y técnicos, o incluso a un centro de monitoreo de operaciones centralizado. No es necesario que el monitoreo y la notificación sean complejos para que resulten eficaces.

4|Transmisores compartidos

Utilizar monitoreo de vibración en tiempo real en equipos rotantes de gran tamaño o críticos puede aportar al personal de mantenimiento información valiosa acerca de la salud de sus activos.

Sin embargo, el monitoreo continuo de una bomba o un motor quizás no sea necesario. En la mayoría de las aplicaciones se considera aceptable monitorear un activo rotante durante un corto período de tiempo, digamos 5 minutos, y luego usar el mismo transmisor para monitorear otros motores o bombas. Con esta implementación se necesitan todavía sensores en cada componente de los equipos, pero ahora es posible compartir un transmisor, lo que reduce costos. Esto permite implementar un sistema con varios piezo sensores de aceleración en tándem cableados a través de relés de modo que el transmisor monitoree un dispositivo por vez.

La recolección de datos se puede simplificar utilizando un PLC con el transmisor y los relés en un solo nodo. El controlador puede conmutar los relés y recolectar la información de vibración de los correspondientes motores o bombas.

Página 1 de 13

Elementos - Pdfs

Auspiciantes

Schneider Electric

 

Endress+Hauser

 

ESCO

 

Honeywell

 

Yokogawa

 

AADECA

© 2018 Editorial Control. Desarrollado por Estudio Pionero.