Arquitectura de un sistema ESL: etiquetas, red, plataforma y datos

Las cuatro capas de un sistema ESL

Cuando alguien dice "etiquetas electrónicas" suele pensar solo en la pantalla del anaquel. En la práctica, un sistema ESL es una cadena de componentes y cada uno tiene dueño distinto. La documentación de fabricantes lo muestra con claridad: el manual Nebular Plus V1.0.5 de Hanshow describe un sistema con etiquetas, controlador (también llamado punto de acceso o AP), software de gestión de la tienda, base de datos, servidor de integración, monitoreo en nube y una terminal de mano para el personal. La guía de despliegue ESL de H3C lo simplifica en cuatro capas: cliente (las etiquetas), acceso (los controladores), red y aplicación de servicio (el sistema de gestión).

Esta división sirve para saber en qué capa buscar cuando algo falla: una etiqueta que no cambia puede tener un problema de radio, red, plataforma o datos, y cada caso lo resuelve un proveedor distinto.

La etiqueta: pantalla, radio y batería

La etiqueta es un dispositivo pequeño con pantalla de papel electrónico, radio y batería. No decide nada: recibe una imagen o un conjunto de datos y los muestra. La pantalla conserva la imagen sin consumir energía, y eso explica su larga duración de batería, pero también implica que lo que se ve en el anaquel es únicamente lo último que la etiqueta aceptó.

Las características cambian por familia y por tamaño. El manual Nebular Plus V1.0.5 de Hanshow, por ejemplo, lista once tamaños y colores negro, blanco, rojo y amarillo, con los modelos de congelador limitados a blanco y negro. La ficha Newton Pro v3.0.0 de SOLUM distingue modelos estándar y de congelador, con rangos de temperatura distintos y comunicación por 2.4 GHz con cifrado AES de 128 bits. No existe una etiqueta "genérica": hay que revisar la ficha del modelo exacto que se va a cotizar.

Gateways y puntos de acceso: el puente de radio

Las etiquetas no se conectan al Wi-Fi de la tienda como un celular. Hablan con un gateway por un protocolo propio del fabricante o, en equipos más nuevos, por Bluetooth. La página de Bluetooth SIG sobre ESL explica que durante años estos sistemas usaron protocolos propietarios y que se creó un perfil estándar de ESL basado en Bluetooth para lograr interoperabilidad entre proveedores. La guía de Cisco Meraki para Vusion añade una advertencia útil: las etiquetas de alta frecuencia propietaria y las de Bluetooth ESL requieren hardware distinto, así que no basta con "tener ESL".

Hay tres formas comunes de proveer la cobertura. Vusion las llama nativa (usa los puntos de acceso Wi-Fi existentes), integrada (poco hardware adicional) y autónoma (red dedicada). Fortinet documenta el caso de dongles USB del fabricante conectados a sus puntos de acceso, y Cisco el de puntos de acceso que alojan la aplicación del fabricante en un contenedor. Cada modelo de AP compatible aparece en listas explícitas, de modo que reutilizar la red existente solo funciona si el modelo y el firmware están en esa lista.

Qué le exige el sistema a la red de la tienda

El gateway necesita alimentación y salida a la plataforma. La guía de H3C da límites concretos: el puerto USB del AP viene deshabilitado por defecto, solo funciona con cierto nivel de alimentación, y en nivel medio la capacidad MIMO baja de 4x4 a 2x2. Además, tras reiniciar el AP hay que reconfigurar la interfaz dinámica del controlador, y se recomienda una VLAN separada para ESL y desactivar las radios de 2.4 GHz del AP para no afectar la velocidad de actualización.

La guía de Cisco indica destinos y puertos que el firewall debe permitir hacia los servidores del fabricante, y que el uso ESL es excluyente con otras funciones IoT del mismo AP, como Bluetooth o MQTT. Todo esto son detalles de diseño que hay que revisar con el equipo de redes antes de la compra, no durante la instalación.

La plataforma: dónde se genera lo que se muestra

La plataforma recibe los datos del producto, aplica una plantilla de diseño por tamaño de etiqueta, genera la imagen y envía la orden al gateway. También guarda la relación entre cada etiqueta y su producto. Puede estar en la nube del fabricante, en un servidor propio o en una mezcla. La página de Pricer Plaza presenta un modelo nativo de nube con vistas por rol y una aplicación móvil; el documento de EWS describe en cambio un software independiente que corre localmente y argumenta a favor de operaciones sin dependencia de internet, aunque se trata de un integrador con su propio interés comercial.

Lo importante es qué sucede con sus datos y con su operación si el servicio no está disponible; el artículo sobre caídas de internet lo profundiza.

Los datos de origen y la fuente del precio

Los precios nacen en el ERP, el POS o un sistema de precios. La plataforma ESL no debería inventar precios: debería recibirlos y publicarlos. Si en la tienda existe más de una fuente (por ejemplo, el ERP para el precio base y una hoja de cálculo para promociones locales), las etiquetas heredarán esa inconsistencia con total fidelidad. Un sistema ESL no corrige procesos de precio desordenados, los hace visibles más rápido.

Conviene documentar tres cosas desde el diseño: qué sistema es la fuente oficial por tipo de precio, con qué frecuencia y por qué mecanismo llega a la plataforma (archivo, API, integración nativa), y quién autoriza cambios manuales de emergencia en la plataforma. Esa política evita discrepancias entre anaquel y caja, tema que se desarrolla en el artículo sobre una sola fuente de precio.

Matriz de responsabilidades para pedir a cada proveedor

Antes de comparar cotizaciones, arme una tabla simple de quién responde por cada capa. Si dos proveedores dicen "eso lo ve el otro", el hueco queda sin dueño.

Un ejemplo hipotético: si una tienda quiere usar su red Wi-Fi existente como cobertura ESL, la pregunta a TI no es "¿hay Wi-Fi?", sino "¿el modelo de AP y su versión de firmware aparecen en la lista oficial del fabricante de etiquetas?". Si la respuesta es no, hay que presupuestar gateways dedicados.

Errores comunes y siguiente paso

El error más repetido es evaluar solo la etiqueta y dejar red y datos para después. El siguiente paso razonable es pedir a cada proveedor el diagrama de arquitectura de su caso, con lo que él entrega y lo que depende de usted. Si desea comentar el caso, puede escribir a ARKCOM en garkcom.com/contact.