El estudio se desarrolló bajo un enfoque aplicado, orientado al diseño y validación funcional de un prototipo tecnológico. El diseño fue experimental de laboratorio en ambiente simulado, debido a que las pruebas se realizaron en una red local controlada y no en una línea de producción industrial en operación. La unidad funcional de análisis fue el evento de trazabilidad generado por una estación de maquinado, compuesto por datos de orden, operador, cantidad de piezas, fecha, hora, estado del pedido y estación de origen.

El prototipo integró dispositivos Raspberry Pi 5, una computadora utilizada como servidor local, interfaces desarrolladas en Node-RED, comunicación mediante el protocolo MQTT y un script en Python para la creación de bloques.

La Raspberry Pi 5 es una microcomputadora de placa única que permite conectar periféricos y dispositivos externos mediante puertos de comunicación y entradas/salidas de propósito general. En el prototipo se empleó como estación de maquinado para desplegar la interfaz de usuario de los operadores, registrar las piezas mecanizadas y enviar los datos hacia la blockchain mediante la comunicación MQTT. El modelo utilizado correspondió a Raspberry Pi 5 con 4 GB de memoria RAM (Figura 1).

La computadora o equipo portátil funcionó como servidor local del prototipo. Desde este dispositivo se ejecutó la interfaz de usuario destinada al rol de gerencia, a través de la cual se consultaron los registros de producción enviados por las estaciones de maquinado y almacenados en la blockchain. La comunicación entre el servidor y las estaciones se realizó dentro de la misma red Wi-Fi (Figura 2).

MQTT se utilizó como protocolo de comunicación entre el servidor, denominado broker, y los clientes, representados por las Raspberry Pi ubicadas en las estaciones de maquinado. Este protocolo permite el intercambio de mensajes mediante topics definidos para cada tipo de evento, lo que facilita el envío de datos desde las estaciones hacia el script de blockchain y la consulta posterior desde Node-RED. De acuerdo con Chen et al. (2020), MQTT resulta pertinente para aplicaciones IoT que requieren comunicación continua y ligera en comparación con protocolos que no mantienen conexiones persistentes.

Node-RED se empleó como entorno de integración y programación por flujos. La herramienta permitió conectar hardware, servicios, nodos de comunicación y scripts externos. Para el prototipo se utilizaron nodos orientados a ejecutar código Python, construir interfaces de usuario mediante dashboard, manejar formatos de fecha y hora, y enviar notificaciones por Telegram ante inconsistencias detectadas en la cantidad de piezas o en el estado del pedido (Figura 3).

Node-RED también se encargó de iniciar el script en Python que genera la blockchain y de alimentarlo con la información proveniente de las estaciones de maquinado. La Figura 4 presenta una salida de depuración en la que se evidencia el registro del bloque génesis y el hash asociado al último bloque disponible.

Para estructurar el prototipo se revisaron arquitecturas de blockchain considerando seguridad, escalabilidad y facilidad de integración con la infraestructura disponible. A partir de la propuesta de Raja Santhi y Muthuswamy (2022), se adoptó una arquitectura por capas conformada por aplicación y presentación, consenso, red, datos y hardware/infraestructura (Figura 5).

La capa de aplicación y presentación se desarrolló en Node-RED, que actuó como puente entre las interfaces de usuario, los dispositivos físicos y el script de blockchain. La capa de consenso se adaptó mediante una lógica de validación inspirada en la prueba de trabajo (PoW), orientada a verificar la coherencia entre la cantidad de piezas reportadas por estaciones consecutivas y el estado del pedido. Cuando el pedido se encontraba concluido y la cantidad reportada no coincidía con la solicitada por el cliente o con la registrada por la estación anterior, el sistema emitía una alerta por Telegram y evitaba la creación de un nuevo bloque. La capa de red se implementó mediante MQTT, la capa de datos mediante el script en Python y la capa de hardware mediante Raspberry Pi 5. La tabla 1 muestra las fases metodológicas seguidas desde la arquitectura funcional hasta el ejercicio de validación.

Las variables técnicas consideradas fueron: registro de eventos de producción, generación de bloques, consulta de registros, emisión de alertas, accesibilidad de la interfaz por perfil de usuario y consumo energético aproximado del hardware. Como indicadores preliminares, se consideraron la creación exitosa de bloques, la recepción de mensajes MQTT, la activación de alertas ante inconsistencias y el consumo en W de los dispositivos comparados. No se reportaron mediciones instrumentales de latencia, tasa de error o costo total de propiedad; por tanto, estas dimensiones se presentan como observaciones preliminares y como criterios para futuras validaciones.

El prototipo permitió implementar un sistema de trazabilidad en una línea de producción simulada mediante la integración de Raspberry Pi 5, Node-RED, MQTT y una blockchain privada. Las pruebas funcionales evidenciaron la posibilidad de registrar órdenes, asociar eventos a operadores y estaciones, generar bloques, consultar registros desde la interfaz de gerencia y emitir alertas cuando se detectaron inconsistencias en el flujo de piezas. La Tabla 2 presenta el pseudocódigo general del sistema.

La interfaz de usuario desarrollada en Node-RED permitió registrar órdenes nuevas con información de fecha, cliente, diseño, cantidad solicitada, descripción del material y número de ítem (Figura 6). Estos datos se enviaron a los dispositivos vinculados al proceso de maquinado específico y quedaron disponibles para su registro en la blockchain.

El acceso a las interfaces se realizó desde dispositivos conectados a la misma red Wi-Fi que las estaciones Raspberry Pi. El sistema contempló perfiles diferenciados para operadores y gerentes, lo que favorece la separación de funciones entre captura de datos y supervisión del proceso.

Cada estación de maquinado contó con una interfaz para el operador. Al activar el registro, el operario podía escanear un código QR que contenía la información personal necesaria para asociar el evento a un usuario. En cada registro se almacenaron fecha, hora, piezas mecanizadas y estado del pedido. Cuando todas las operaciones del proceso se reportaban como concluidas, el sistema validaba la cantidad de piezas a entregar al cliente (Figura 7).

Los resultados deben interpretarse como una validación funcional preliminar, debido a que las pruebas se realizaron en red doméstica, con volúmenes de datos controlados y simulación de una línea de producción. En este contexto, se comprobó la comunicación entre dispositivos, la generación de bloques y la emisión de alertas; sin embargo, no se realizaron mediciones instrumentales suficientes para afirmar reducciones cuantitativas de errores, desperdicios o costos operativos (tabla 3).

Respecto al consumo energético, la Raspberry Pi 5 presentó valores aproximados de 2,5 W en reposo y 12 W en consumo máximo. Estos valores resultan menores que los reportados para un servidor típico, aunque deben interpretarse con cautela porque pueden variar según periféricos, carga de trabajo y configuración específica. En este prototipo se consideró como dispositivo externo principal la cámara web para escaneo de códigos QR.

Los valores de la Tabla 4 son aproximados y pueden cambiar según la configuración específica, los módulos conectados y la carga de trabajo. En el caso de controladores lógicos programables (PLC), el consumo depende del número de módulos, entradas y salidas conectados.

La integración de IoT y blockchain observada en el prototipo coincide con la literatura que reconoce el potencial de estas tecnologías para fortalecer transparencia, trazabilidad y seguridad de datos en cadenas productivas (Kshetri, 2018; Shahbazi & Byun, 2021). A diferencia de soluciones empresariales comerciales, el sistema propuesto se orienta a una implementación de bajo costo y modular, lo que puede ser pertinente para pequeñas y medianas empresas que requieren digitalizar procesos de manera progresiva.

El uso de una blockchain privada reduce los requerimientos energéticos y computacionales asociados a blockchains públicas de gran escala, lo que resulta coherente con la necesidad de soluciones más eficientes para aplicaciones industriales e IoT (Habibullah & Lu, 2024). No obstante, esta ventaja debe ponderarse frente a retos como autenticación robusta, protección frente a ciberataques, respaldo de información, disponibilidad de red, interoperabilidad con sistemas ERP o PLC y validación bajo tráfico de datos real.

Las principales limitaciones del estudio son: uso de una red doméstica, ausencia de pruebas en una línea industrial real, falta de métricas cuantitativas de latencia y tasa de error, ausencia de análisis económico completo y necesidad de fortalecer los mecanismos de seguridad. Por ello, los resultados no deben presentarse como evidencia concluyente de reducción de costos, errores o desperdicios, sino como una validación funcional inicial del diseño propuesto.

Como línea futura, la implementación en ambientes industriales reales debería incorporar indicadores de desempeño como latencia promedio, pérdida de paquetes, tasa de registros rechazados, tiempo de consulta, costo por nodo, disponibilidad del sistema y consumo energético bajo diferentes cargas. También sería pertinente integrar análisis de datos e inteligencia artificial para identificar patrones de fallas, optimizar recursos y apoyar decisiones en tiempo real, en consonancia con las tendencias de digitalización de la manufactura y el metaverso industrial (Mourtzis et al., 2023).