Cuando un fabricante de máquinas decide embarcarse en su propia misión de digitalización, sus mantras incluyen “los datos son el nuevo oro” y “recogeremos todos los datos, averiguaremos qué hacer con ellos más adelante”. Con esto, un componente clave es la recopilación de datos OT (Tecnología Operativa), lo que normalmente se refiere a la información del lado de automatización de la planta. Desafortunadamente, sin una visión clara de qué hacer con estos datos de OT, estas iniciativas de digitalización pronto pueden desmoronarse. Según un informe de Microsoft Signal de 2019, casi un tercio de todas las pruebas de concepto de IoT falla. Una de las razones clave es el alto costo de escalamiento. Además del costo bruto, se hace difícil justificar un caso de negocios sin un impacto real a corto plazo. Por último, los pilotos demuestran un valor comercial o un retorno de la inversión poco claro. La comparación del alto costo de la recopilación de datos y el escalamiento con poco valor final hace que estos proyectos se detengan o se cancelen. Pero, antes de continuar, tomemos un paso atrás.

Los datos recopilados de las capas de automatización de una planta son ricos en detalles. Desde el PLC de la máquina hasta la E/S y los diversos sensores repartidos, el usuario puede darse cuenta de muchas situaciones a partir de estos datos. A partir de nuestra propia investigación, hay dos aplicaciones principales para datos de máquina u OT:

• Dashboards (tableros): Las aplicaciones de tablero son visualizaciones sencillas que constan de gráficos circulares, gráficos de barras y alarmas, con el fin de supervisar, casi en tiempo real, el estado y el rendimiento del equipo de automatización.

Dado que un dashboard depende de datos casi en tiempo real, no es necesario determinismo ni precisión histórica.

Si faltan los datos de hace uno o dos segundos, no es una pérdida porque el usuario solo se preocupa realmente por el estado en este momento. Por lo tanto, una cantidad razonable de pérdida de datos es aceptable. Por último, dado que los datos son necesarios inmediatamente, cualquier procesamiento que se necesite tiene lugar dentro de la propia aplicación. Por lo tanto, no se realiza ningún procesamiento previo (ni es necesario) a los datos antes de enviarlos a la aplicación de panel.


• Analítica: Las aplicaciones de analítica son visualizaciones más complejas que consisten en gráficos de tendencias y análisis históricos. Para que estos análisis proporcionen información significativa, solo se deben proporcionar datos relevantes a la aplicación. Esto significa que una buena cantidad de procesamiento de datos debe tener lugar antes de ser enviado a la aplicación final de análisis.

Filtrar los datos y proporcionar conjuntos de datos de calidad es crucial para que la aplicación identifique las relaciones causa-efecto y, en última instancia, mejore el rendimiento de la máquina. Además, estos conjuntos de datos deben completarse sin pérdidas ni incoherencias. Los duplicados y los valores ordenados incorrectamente reducen la calidad de un conjunto de datos y ambos deben ser capturados antes de ser enviados a la aplicación.

En los primeros pasos de una estrategia de digitalización, es necesario hacer una clara distinción entre los tipos de aplicación. Como se puede ver, estas dos aplicaciones tienen requisitos muy diferentes y creemos que esta es una razón clave por la que las iniciativas de digitalización finalmente fracasan. De hecho, recopilar todos sus datos de la manera más rápida posible conducirá a graves ineficiencias. Un estudio encontró que el 30% de los profesionales de Business Intelligence pasan entre el 50% y el 90% de su tiempo haciendo que sus datos estén “listos para análisis”.

Mientras que la mayoría de los fabricantes de máquinas comienzan sus proyectos con un dashboard simple en mente, su objetivo es obtener información sobre su flota de máquinas lo más rápido posible. Como resultado, deben estar apuntando a una aplicación de análisis. Un buen hito suele ser una aplicación de mantenimiento preventivo. Continuaremos este artículo suponiendo que una aplicación de mantenimiento preventivo o predictivo será la primera gran implementación de aplicaciones IIoT.

Si un fabricante de máquinas está tratando de diseñar su estrategia para abordar aplicaciones de panel y análisis a la vez, puede haber demasiados datos (o no suficientes datos estructurados) con el fin de proporcionar un retorno real de la inversión. No es de extrañar que menos del 1% de los datos no estructurados se analicen o utilicen en absoluto. Tratar de recopilar tantos datos como sea posible, tan rápido como sea posible, es una manera segura de alcanzar costos de escalamiento insostenibles. Y como se mencionó anteriormente, esta es la razón número 1 por la que el 33% de todos los proyectos de digitalización fracasan.

Los costos de escalado aumentan rápidamente debido a 2 razones principales:

• Ampliar una prueba de concepto es complicado: Si alguna vez ha configurado una simple transferencia de datos punto a punto, es posible que se deje engañar pensando que escalar el proyecto será igual de fácil. Pero el problema con la omnipresencia de la prueba de concepto (PoC, por sus siglas en inglés) de IoT es que para el PoC es fácil de despegar. Solo está recopilando datos de un puñado de sitios. No obstante, cuando llega el momento de expandir la recopilación de datos a fábricas alrededor de todo el mundo, o varias máquinas en la misma fábrica, estos costos se multiplican rápidamente.

Un proveedor de software de confianza nos dijo que cada sitio tarda aproximadamente 2 horas de tiempo de ingeniería para que la recopilación de datos de PLC funcione correctamente con su servidor remoto. Para proyectos pequeños con solo 5 o 10 máquinas, esto no es un gran problema. Pero expanda esta cantidad de tiempo a la magnitud de un fabricante de máquinas global, y todos los beneficios potenciales de costos ya han desaparecido.

Además, los ámbitos del proyecto cambian. Las etiquetas recopiladas, la forma en que se procesan, y a veces incluso el cambio de aplicación final. Estos cambios pueden parecer triviales, pero resultan en horas de ingeniería reales. Una vez más, multiplique esto por el número de sitios, y se convierte en una carga para administrar. Por último, la prueba de concepto a veces está a merced del propietario de la fábrica. El mantenimiento de TI y varios otros procedimientos de rutina podrían impedir que los datos clave se envíen a su aplicación de IoT. Si no tiene una forma de almacenar en búfer e historizar los datos, es posible que se pierdan eventos críticos para el análisis.


• Los costos de los datos en la nube se suman: Tanto Azure como AWS ofrecen tarifas y servicios razonables para comenzar en sus plataformas. Incluso pueden ofrecer reembolsos, promociones y ofertas especiales para que consumas “todo lo que quieras”. Si bien los costos de almacenamiento de datos son muy razonables, los costos de ingesta de datos son una historia diferente. Estos son los costos para introducir los datos en las plataformas en la nube.

Cuando un fabricante de máquinas busca una aplicación de análisis, el filtrado de los datos antes de su ingesta es la forma más ideal de administrar sus costos. De lo contrario, se requiere una cantidad decente de postprocesamiento una vez que se introduzcan los datos, y los costos informáticos aumentan drásticamente el costo total de propiedad.


Pero ¿qué pasaría si estos costos de escala pudieran mitigarse? ¿Y si la expansión de su PoC a un piloto en toda regla tomara unos pocos minutos? ¿Qué sucede si puede optimizar sus datos para alimentar correctamente su aplicación de análisis?

A medida que observamos cómo evolucionaban las necesidades y expectativas de los clientes, nos dimos cuenta de que era necesario un nuevo método para recopilar y administrar datos de OT, el que tuviera como base que los conjuntos de datos históricos correctamente ordenados, ordenados y “limpios” serían críticos para la primera oleada de aplicaciones de IoT, como análisis y mantenimiento preventivo. Además, los desarrolladores de estas aplicaciones no serían expertos en el mundo de OT, por lo que recopilar datos de varios sitios debe ser fácil, intuitivo y seguro.

A raíz de esta hipótesis, muchas mejoras clave se convirtieron en las características que debe tener un servicio de recopilación de datos IoT:

• Datos almacenados en búfer en un servidor intermediario (con certificación ISO 27001).

• Sin pérdida de datos, sin duplicados y un conjunto de datos correctamente ordenado.

• Los conjuntos de datos históricos se recuperarían cada 10 minutos.

• Configuración simple y fácil.


Más recientemente, a esta lista se ha sumado la integración de servicios para filtrar solo datos relevantes, evitamos duplicados y costos innecesarios de ingesta de datos. De igual importancia, la nueva forma de recopilar datos de IoT proporciona una API REST pública para que los desarrolladores modernos puedan implementar e integrar un conector fácil de usar en su aplicación.

Esta API abierta alivia enormemente la carga para los desarrolladores al evitar el bloqueo. En cuestión de horas, los desarrolladores pueden simplificar su recopilación de datos a escala. ¿Necesita recopilar datos de 5 sitios? Solo se necesita una llamada a la API. ¿Ha aumentado el alcance del proyecto y ahora necesita recopilar datos de 50 sitios? Sin embargo, solo se necesita una llamada a la API. Si bien los beneficios son increíbles para el proveedor de aplicaciones de IoT, los clientes finalmente ganan.

Mediante la implementación de un conector, se brinda un enfoque centrado en el cliente en la aplicación de IoT industrial moderna. Con solo sus credenciales, un cliente puede evaluar y visualizar rápidamente sus datos en cualquier aplicación IoT compatible.

Pero, lo más importante es que pueden dejar de preocuparse por cómo recopilar datos y, en su lugar, centrarse en su aplicación de IoT, pues los costos de escalamiento se gestionan debido a los servicios de filtrado, clasificación y eliminación de duplicaciones.