Middleware RFID: qué debe resolver entre lectores y sistemas

Qué problema existe entre un lector y un sistema empresarial

Un lector fijo entrega, en esencia, listas de etiquetas vistas por una antena en un momento dado. Un WMS espera algo muy distinto: documentos, cantidades, ubicaciones válidas. Entre ambos hace falta un traductor con memoria y reglas. A esa capa se le llama middleware, aunque algunos fabricantes la integren al lector, a un servidor local o a un servicio en la nube.

La arquitectura descrita en el estándar EPCIS de GS1 nombra explícitamente este estrato: un nivel de filtrado y colección que entrega listas de EPC sin duplicados según criterios definidos, y una capa de flujo de trabajo que aporta contexto del proceso. Es un modelo conceptual útil para saber qué pedirle a cualquier producto, sin que exija usar EPCIS.

Funciones que debe resolver

Observa que ninguna fila habla de velocidad de lectura. Eso corresponde al lector y a la instalación física; el middleware se juzga por cómo maneja el desorden.

Deduplicar sin borrar información real

La deduplicación parece trivial hasta que aparecen casos reales. Si el mismo EPC se lee en la zona de recepción y de nuevo en la de almacenamiento treinta minutos después, no es un duplicado: es un movimiento. Por eso conviene que la regla incluya al menos tres elementos: el identificador, la sesión o ubicación lógica, y una ventana de tiempo. Una deduplicación solo por EPC sin contexto aplana la historia.

Otro cuidado: las lecturas ajenas. Una etiqueta de un pasillo cercano puede aparecer porque la señal llega más lejos de lo previsto. Filtrarla por antena o por intensidad de señal ayuda, pero no es una garantía; la validación posterior contra la orden o la lista de artículos esperados sigue siendo necesaria.

Monitoreo: enterarse antes de que falte inventario

Un lector puede seguir encendido y aun así dejar de leer porque una antena se desconectó o un cable se dañó. Si nadie lo vigila, el síntoma aparece días después como diferencias de inventario. Pide que el middleware muestre, como mínimo, el último momento en que cada lector reportó, el número de lecturas por antena en una ventana reciente y el tamaño de la cola de eventos pendientes. Define quién recibe la alerta y qué hace con ella; una alerta sin dueño es ruido. Prueba además el caso inverso: apaga una antena a propósito durante el piloto y comprueba cuánto tarda alguien en notarlo.

Ejemplo hipotético: tres lectores en un muelle

Ejemplo ilustrativo. Un muelle tiene tres lectores fijos, uno por andén. Un operador abre en su terminal la sesión del embarque “E-100” en el andén 2. Mientras tanto, el andén 1 también carga. El middleware asocia cada lectura al andén de la antena que la detectó y a la sesión abierta en ese andén. Un EPC visto por el andén 1 mientras la sesión del andén 2 está activa se marca como “fuera de sesión” y se envía a un registro de excepciones en lugar de al evento del embarque.

Si el servidor del WMS se cae diez minutos, el middleware guarda los eventos localmente y los reenvía con el mismo identificador cuando el destino responde. El WMS puede así detectar un reenvío. Sin ese identificador, el reintento generaría un duplicado, algo que se aborda con más detalle en el artículo de idempotencia.

Seguridad y operación diaria

Un middleware es un punto de concentración: recibe datos de dispositivos y habla con sistemas empresariales. Trátalo como cualquier servicio con credenciales. El documento NIST SP 800-213 plantea considerar los requisitos de ciberseguridad de un dispositivo IoT según el sistema donde se integrará; úsalo como marco de preguntas para el proveedor, no como certificación de nada.

En registros, guías como la hoja de OWASP sobre logging recomiendan no guardar tokens, contraseñas ni claves, y proteger los logs contra manipulación. Aplica aquí: el middleware suele registrar mucho, y esos registros son parte del perímetro.

Por qué no hay una pila universal

Algunos lectores traen una capa de aplicación incluida; otros dependen de un software externo; algunas soluciones de ERP ya incorporan una interfaz RFID. La combinación correcta depende del número de sitios, de si hay conexión confiable, de quién dará soporte y de qué sistemas destino existen. Pide a cada proveedor que describa, para tu caso, dónde corre cada función de la tabla y quién la mantiene. Si la respuesta es “todo”, pide el detalle.

Siguiente paso

Convierte la tabla de funciones en un cuestionario y pide a cada proveedor que responda con un escenario tuyo: cuatro andenes y un destino que se cae. Las respuestas concretas separan lo que existe de lo que se promete. Para comentar tu caso, puedes escribir a ARKCOM en garkcom.com/contact.