Aplicación técnica · IIoT industrial
Del sensor al KPI: cómo relacionar energía, producción y paradas sin perder el contexto
Medir consumo es relativamente simple; convertirlo en una decisión exige relacionar cada señal con el estado de la máquina, la orden y las causas de parada.
Durante el turno noche, una máquina consume casi lo mismo que cuando produce, pero entrega menos piezas. El medidor registra potencia y energía; el PLC conoce marcha, espera y falla; producción conserva la orden en una planilla; mantenimiento anota la causa de algunas paradas. Cada fuente describe una parte del problema, aunque ninguna permite explicar por sí sola dónde se pierde energía o capacidad.
Un tablero con gráficos puede mostrar la anomalía y aun así dejar abierta la pregunta principal: ¿el consumo aumentó por una condición del proceso, por una espera con motores encendidos o porque el dato de producción llegó incompleto? Pasar del sensor al KPI requiere conservar el contexto que permite responderla.
Una medición correcta todavía puede ser inútil
Un analizador de energía puede entregar tensión, corriente, potencia, factor de potencia y energía acumulada. Para transformar esos valores en consumo por pieza hace falta conocer cuántas unidades aceptadas produjo la máquina en el mismo intervalo. Si se busca consumo improductivo, también hay que distinguir marcha, preparación, espera, alarma y equipo detenido.
El problema aparece cuando cada señal utiliza tiempos, nombres o frecuencias distintas. Un cambio de estado del PLC puede durar segundos; la orden se actualiza al terminar el lote; los rechazos se cargan después. Dividir energía diaria por producción diaria genera un indicador, pero puede ocultar una hora completa de espera o atribuir el consumo de una preparación a la orden equivocada.
Por eso conviene definir primero la decisión que se quiere tomar. Detectar una espera con motores en marcha requiere señales diferentes de las necesarias para comparar recetas, turnos o referencias. El KPI debe especificar fuente, unidad, ventana temporal, condiciones de exclusión y responsable de validar el resultado.
La cadena que debe permanecer trazable
Según la documentación de ThingsBoard, la plataforma puede almacenar telemetría como series temporales y procesar mensajes mediante cadenas de reglas. También permite organizar dispositivos y activos y representarlos en tableros. Esas son capacidades declaradas por el producto; no garantizan que los datos de una planta lleguen completos ni que un indicador esté bien definido.
En una arquitectura acotada, el medidor y las señales de máquina llegan a un PLC o gateway industrial. Allí se normalizan identificadores, unidades y marcas de tiempo. La plataforma recibe telemetría, conserva eventos y muestra tendencias. La orden, el lote o la referencia pueden incorporarse desde una selección del operario o desde el sistema de producción.
La trazabilidad debería permitir retroceder desde un KPI hasta los datos que lo componen. Si el tablero muestra un aumento del consumo específico, el usuario necesita ver el intervalo, la orden activa, el tiempo en cada estado, la cantidad aceptada y cualquier dato faltante. Sin ese recorrido, discutir el indicador se convierte en discutir cuál planilla tiene razón.
Un piloto sobre una sola máquina
Una primera evaluación puede concentrarse en una máquina con una pérdida visible y adquirir energía, marcha, espera, falla, conteo de piezas y referencia activa durante cuatro a seis semanas. Ese período permite comprobar la calidad del dato antes de definir alarmas, reglas o acciones de mejora.
Antes de instalar, producción y mantenimiento deberían acordar qué significa cada estado y cómo se confirma una causa. Durante el piloto conviene revisar períodos concretos con quienes operan la máquina. Una alarma del PLC puede explicar una parada; una espera por material quizá necesite una confirmación manual. El objetivo es comprobar si el dato representa lo que efectivamente ocurrió.
Los criterios de aceptación pueden ser:
- señales disponibles y estables durante el período acordado;
- estados mutuamente comprensibles para producción y mantenimiento;
- energía asociada al intervalo y a la referencia correctos;
- registro visible de datos faltantes y correcciones;
- dos o tres pérdidas sobre las que pueda tomarse una acción concreta.
Factory I/O puede utilizarse antes de intervenir la planta para simular sensores, actuadores y secuencias conectadas con un controlador. Sirve para probar estados, fallas y el recorrido de los datos. No reproduce por sí solo el comportamiento energético real de una máquina ni reemplaza la validación con señales de campo.
Responsabilidad por el dato y por su uso
Nodira puede ayudar a definir e implementar la capa de medición, adquisición, conectividad y visualización, con ThingsBoard como una alternativa de plataforma cuando encaje con la aplicación. El alcance debe indicar qué señales son directas, cuáles se calculan y cuáles dependen de una carga humana o de otro sistema.
El paso siguiente es validar los indicadores con producción y mantenimiento. Cuando existe una base confiable, el sistema puede ampliarse con seguimiento periódico, nuevas reglas, alarmas o incorporación de más máquinas. Así, el tablero queda vinculado a una práctica de revisión y puede mantenerse a medida que cambia la instalación.
Una evaluación inicial debería elegir una máquina, una decisión y un responsable. Por ejemplo: identificar por qué aumenta la energía consumida fuera del tiempo productivo y comprobar durante un mes si las causas registradas permiten reducirla. La plataforma se selecciona después de definir esa pregunta, no antes.