Cuando preguntas a las personas sobre el Internet Industrial de las Cosas (IIoT), rara vez se escucha que una empresa lo haya implementado con éxito. Si lo has intentado, o estás pensando en hacer un proyecto de IIoT, esto es lo que necesitas saber para poner tu proyecto en marcha en DÍAS frente a semanas o meses.
En este texto, exploraremos las tres razones fundamentales por las que sus proyectos de IIoT no ven la luz durante la implementación y, en un artículo posterior, revelaremos los tres secretos para superar cada uno de estos obstáculos.
- ¿Conectar dispositivos? Resulta más fácil decirlo que hacerlo. Incluso si los dispositivos están conectados, a menudo no hay herramientas simples para administrarlos y obtener los datos de un “lenguaje” para pasarlo a otro. Por ejemplo, ¿cómo puedes meter datos de un controlador lógico programable (PLC) en tu sistema de planificación de recursos empresariales (ERP) de forma limpia y sencilla?
- El código personalizado coloca grilletes en tu sistema automatizado. Conseguir que todos los dispositivos heredados se comuniquen a todos tus dispositivos modernos y, a continuación, conectar esa red a tu sistema automatizado requiere una gran cantidad de código personalizado porque debes tener en cuenta todos los diferentes protocolos y marcas.
- El IIoT por sí mismo no te otorga escalabilidad. La escalabilidad se vuelve costosa cuando tienes que agregar más equipos, servidores o nodos para administrar más y más dispositivos a medida que crece el despliegue.
Los proyectos se estancan, o incluso fracasan, a medida que su equipo se encuentra con estos problemas. Los fabricantes que aprendan los secretos para superar estos tres puntos de “estrangulamiento” serán los que ganen en IIoT. Este artículo técnico mostrará cómo llegar hasta ese punto. Es más, hablaremos de cómo llegar rápidamente.
¿Por qué los proyectos de IIoT no ven la luz durante su implementación?
Punto de Estrangulamiento #1
¿Conectar dispositivos? Es más fácil decirlo que hacerlo
¿Por qué es tan difícil conectarse? Muchos proveedores de IIoT lo ignoran. Dicen, "conéctate" y luego te muestran grandes análisis y exponen algunos servicios que puedes hacer. Una vez que los fabricantes deciden dar el paso, de repente se dan cuenta de que conectarse a todos estos dispositivos diferentes - heredados, modernos, propios y de código abierto - es realmente difícil. No es imposible, pero la tediosa configuración ha bloqueado el proceso de muchas personas de poner IIoT en funcionamiento.
Si alguna vez has diseñado sistemas de planta, sabrás que hay dispositivos en la planta que son una pesadilla para conectar e integrar con otras aplicaciones. Una tarea simple de recopilación de datos puede tardar semanas en codificarse.
Con una gran demanda de datos de fabricación en tiempo real, la lista de deseos se llena de tareas referentes a la recopilación de datos. Los datos rápidamente deben ser canalizados cuándo, dónde y cómo lo necesitas, para que alguien pueda hacer algo con esa información.
Una tarea simple de recopilación de datos puede tardar semanas en codificarse para que los dispositivos y aplicaciones modernos, heredados, patentados y de código abierto funcionen en conjunto.
Acoge a la complejidad
Con el tiempo, la planta industrial ha evolucionado a medida que la tecnología también lo ha hecho. Esto trajo una gran mejora a los procesos automatizados. Sin embargo, para bien o para mal, este avance también significa más complejidad. Esta complejidad no está desapareciendo; de hecho, ¡va a aumentar!
La complejidad por definición no es algo malo. Este concepto se utiliza generalmente para caracterizar algo con muchas partes que interactúan entre sí de múltiples maneras, culminando en una solución mayor que es la suma de sus partes. Adoptar o acoger a la complejidad significa que aceptamos que hay muchas piezas móviles en las soluciones de IIoT que necesitamos vincular para conseguir finalmente el éxito.
Como resultado, las plantas tienen una mezcla de marcas de dispositivos y diferentes protocolos. Cada mezcla es totalmente única para cada empresa. Muchos dispositivos también utilizan conjuntos de datos propios, lo que hace muy difícil obtener diferentes PLC para compartir datos. A su vez, algunas máquinas nunca fueron construidas para ser conectadas, como las CNC.
No hay una sola manera estándar de conectar todo. En respuesta a la necesidad de la industria, se introdujo el estándar de comunicación OPC. Pero como veremos a continuación, también trae una serie de desafíos en cuestiones de velocidad y precisión de los datos.
Lidia con la latencia
El OPC fue diseñado para proporcionar automatización industrial con un protocolo de red estándar que requiere de un sondeo para recibir datos provenientes de dispositivos. A través del sondeo, el sistema debe "pedir" datos al dispositivo de manera constante a una velocidad preestablecida, una vez cada segundo o una vez cada media hora, por ejemplo.
El OPC también requiere de varios pasos para enviar los datos. Va desde un dispositivo, a un PLC, a un servidor OPC, que luego lo envía a un cliente OPC. A continuación, el cliente OPC lo envía al servidor local o a la red en la nube para utilizarlo y procesarlo. Además, se requiere soporte de TI para los servidores, equipos y software que ejecutan el servidor OPC y el software del cliente OPC. Asimismo, los PLC deben tener conexiones separadas a cualquier otra “cosa” o aplicación de software. Por lo tanto, las conexiones deben escribirse de PLC 1 a la “cosa” 1, PLC 1 a “cosa” 2, PLC 1 a “cosa” 3, y luego repetirse para PLC 2 y su conexión a cada “cosa”. Si se desea obtener datos de PLC en un software ERP, entonces se tendría que escribir una conexión desde PLC 1 al software ERP 1, software ERP 2, etc.
Agrega el sondeo a todas esas capas y conseguirás una gran latencia.
Los datos no siempre son precisos
Otro desafío es la precisión de los datos. El OPC no ofrece ninguna función para garantizar la precisión. Una compañía con una planta farmacéutica en Jacksonville, Florida, se enfrentó a este desafío. Estaban usando OPC para sondear dispositivos, y a menudo recibían 3.000 paquetes de datos para ejecutar cada producción. No tenían manera de verificar qué paquete era el correcto para cada lote del producto terminado.
Para responder a esta cuestión, el equipo de ingeniería escribió una gran cantidad de código personalizado complejo para ejecutar comprobaciones dobles en los orígenes de los datos y los extremos de recepción para garantizar que los datos coincidan. Sin embargo, esto da mucho trabajo en su creación y mantenimiento.
Haz que los dispositivos antiguos se adapten a equipos modernos
MQTT se está convirtiendo rápidamente en uno de los protocolos principales para IIoT, y los dispositivos modernos están llegando a construirse con MQTT. Sin embargo, la única manera de aprovechar MQTT es comprar dispositivos habilitados para MQTT. Nadie quiere extraer y reemplazar los dispositivos antiguos o heredados que ya han amortizado durante 20 o 30 años sólo para renovarlos con nuevos dispositivos MQTT.
Si deseas agregar nuevos equipos en algún momento, como el sensor más reciente que es el elemento más popular del mercado, lo más probable es que se diseñe teniendo en cuenta MQTT. La desventaja es que vas a tener que hacer un trabajo adicional para que los dispositivos MQTT funcionen con tus dispositivos antiguos. Entre los miles de dispositivos que puedes llegar a tener en una planta, es posible que tengas 10 dispositivos equipados con MQTT. La migración de todos los dispositivos a MQTT será lenta y no resuelve el problema actual de conectar dispositivos antiguos y modernos.
De cualquier manera, vas a necesitar hacer más codificación para que las tecnologías nuevas funcionen con dispositivos que están cada vez más obsoletos. Sin embargo, más adelante podremos ver cómo solucionar este problema.
Punto de Estrangulamiento #2
El código personalizado para la interoperabilidad incapacita la movilidad de los datos
La naturaleza compleja de una variedad de proveedores y protocolos, incluso mientras se utiliza OPC y MQTT, todavía requiere el uso de código personalizado. Dado que el código personalizado es necesario, éste se convierte en el segundo punto de estrangulamiento que seca las iniciativas de IIoT.
El tiempo acaba con los proyectos
Los proyectos a menudo se retienen en prioridad porque simplemente tardan demasiado tiempo en codificar. Cuando el tiempo se compara con el valor del proyecto, puede terminarse. Esto sucede más de lo que uno podría pensar.
También está la realidad de que hay otros proyectos de mayor prioridad ya en cola, pero que también sufren una larga espera mientras los programadores trabajan incansablemente.
Los expertos en la materia no pueden operar con agilidad
A menudo, la necesidad de un programador es la brecha entre un experto en la materia y obtener un proceso o producto mejorado. Su trabajo es analizar el proceso y determinar los cambios necesarios. Si sabe lo que tiene que cambiar, pero no puede implementarlo en el proceso, es una oportunidad perdida para que un producto mejore o más productos salgan de las líneas de producción.
Por ejemplo, en una planta lechera que produce queso, se pueden rastrear datos como la temperatura del queso, la temperatura en la instalación, la densidad del producto, etc. El especialista del producto ve los datos y determina que el proceso debe ser ajustado; tal vez la velocidad de una máquina necesita ser ralentizada o acelerada. No quiere preocuparse por ir al programador, ya que está demasiado ocupado, entonces deja una sugerencia y debe esperar unas cuantas semanas.
Estás en riesgo cuando sólo un puñado de personas conocen el código
Cuando el código personalizado es la base para las operaciones de planta se presentan varios riesgos. El primero es que es difícil realizar cambios en un sistema en vivo sin provocar un tiempo de inactividad. El segundo es que una o pocas personas han escrito el código, y sólo ellos están familiarizados con cómo se codifica - cuando no están disponibles o dejan la empresa, los efectos pueden ser perjudiciales.
Otra realidad es que algunos dispositivos funcionan muy bien durante dos o más años y los ingenieros no tienen una razón para trabajar con ellos. Con tanto tiempo de impasse, los ingenieros olvidan cómo trabajar con ese dispositivo específico, y tienen que dedicar su tiempo a reaprender sobre su funcionamiento.
A medida que se va agregando más y más funcionalidad, se termina con una aplicación que solo unos pocos saben cómo cambiar mediante programación. El sistema nunca será ágil o flexible ni ninguna de las cosas que realmente deseas que sea.
Punto de Estrangulamiento #3
El IIot en sí no te da escalabilidad
Uno de los pensamientos predominantes detrás de IIoT es que es una red perfecta y compleja que llega a las profundidades de tu empresa: desde unos pocos sensores de vibración en una cinta transportadora hasta fuera de la planta como datos meteorológicos de drones que vuelan sobre los campos del proveedor. Todo puede y debe estar conectado, en teoría.
Tienes que navegar por las limitaciones del hardware y los costes del software
Con la mayoría de los softwares de automatización industrial o los softwares IIoT, los usuarios tienen que comprar varias instancias de software. Esto se debe a que un nodo o servidor solo puede manejar un cierto número de dispositivos. Para lograr escalabilidad, es necesario comprar varios nodos o servidores, cada uno con una instancia del software que se ejecuta en él.
Los costes de cada servidor, cada nodo, licencias para cada instancia de software, el coste para TI, para mantener esos elementos, etc. se suman. La escalabilidad se vuelve muy costosa cuando se requiere diseñar el sistema para manejar más y más dispositivos a medida que crece la implementación.
Un nodo o servidor de configuración solo puede controlar un cierto número de dispositivos, lo que hace que sea costoso escalar una implementación de IIoT.
Hacer cambios se vuelve más arriesgado para un sistema en constante crecimiento
La mayoría de los cambios y actualizaciones de un sistema automatizado requieren que el ingeniero toque el sistema en vivo. Esto significa que los cambios deben programarse o realizarse durante el tiempo de inactividad planificado para agregarlo. Después esperamos a que todo funcione de la manera correcta cuando el sistema se vuelva a subir. Sin embargo, esta cuestión resulta algo inquietante.
Las actualizaciones no se pueden hacer sobre la marcha. A parte, a menudo el marco existente se ve afectado y los ingenieros tienen que tratar con incógnitas bajo presión para obtener una línea de producción de alto valor. De este modo, cuanto más grande es el sistema, más difícil es actualizarlo continuamente porque hay mucho más en juego.
Ahora que hemos cubierto los tres puntos de estrangulamiento más grandes de IIoT, en un próximo artículo veremos cómo puedes evitarlos con una plataforma de software IIoT centrada en los datos.
¿Quieres adelantarte al artículo y conocer cómo superar los obstáculos? ¡Descarga nuestro nuevo ebook!
