Los equipos están en los locales y usted en la oficina. Les ponemos sensores, los conectamos a internet y mostramos las lecturas en un programa que se abre en el navegador. Si la temperatura se sale de la norma, una puerta se ha quedado abierta o se ha ido la corriente, el empleado responsable recibe un mensaje al instante en lugar de enterarse por la mañana por la mercancía estropeada.
Dicho llanamente: a los equipos se les ponen pequeños dispositivos que miden continuamente lo que importa: la temperatura dentro de una cámara, si una puerta está abierta, si hay corriente, si funciona el compresor. Una vez por minuto esas mediciones van por internet a un servidor. Usted abre un navegador y ve el estado de cada equipo en cada punto.
IoT significa «internet de las cosas». La idea es que no sea una persona quien vaya con una libreta anotando lecturas, sino que los propios equipos las envíen al programa. Para eso no hay que hacer nada: los datos llegan solos, las veinticuatro horas, incluidas noches y fines de semana.
La diferencia principal con una simple pantalla de cifras es que el sistema no espera a que alguien mire. Compara cada medición con la norma que usted ha fijado para ese equipo. Si la norma se incumple, busca en el catálogo al empleado responsable de ese local y le envía el mensaje.
Un ejemplo. En una cámara de congelación del almacén, −18 °C es el nivel admitido. A las 21:04 el sensor comunica −16,8 °C. En ese momento nadie mira la pantalla. Quince minutos después la temperatura sigue subiendo: el sistema crea un evento, anota en él el número de cámara, la dirección del almacén, la hora y el valor actual y envía un mensaje al responsable de guardia del almacén. A las 21:33 llega y encuentra la puerta del vestíbulo mal cerrada. La mercancía está intacta.
No hay que sustituir ningún equipo. La nevera, la máquina expendedora, la bomba o la unidad de ventilación se quedan donde están: se añade lo que les falta, sensores, un dispositivo de comunicación y un software en el que todo el parque se ve como una sola lista.
Cada proyecto empieza con tres preguntas: qué se puede medir físicamente en ese equipo; cómo saldrán los datos del local hacia internet; quién responde de una desviación y en cuántos minutos debe reaccionar. Mientras la tercera pregunta no tenga respuesta, saldrá una pantalla bonita con cifras y no un sistema que evite algo.
| Qué está implementado | A qué equivale |
|---|---|
| La lectura se muestra en pantalla en tiempo real | observación |
| La lectura se guarda en un historial con hora exacta | un cimiento |
| Salirse de la norma se registra como evento propio | un cimiento |
| El evento tiene un empleado concreto y un plazo de reacción | monitorización |
| La reacción del empleado se registra y cierra el evento | monitorización |
La frontera pasa por dos cosas: un evento tiene una persona y tiene un plazo. Una pantalla con la temperatura actual no salva nada por sí misma: mientras no se le haya dicho a nadie que se ocupe, una desviación sigue siendo una línea de un gráfico. Por eso la norma, el responsable, el plazo de reacción y la marca de cierre son campos obligatorios del sistema y no ajustes opcionales.
Los límites de lo posible los pone el equipo y no el software: solo se puede leer lo que él mide o lo que puede medir un sensor, y solo se puede cambiar lo que su controlador permite. Qué hay disponible en su modelo se establece en el estudio previo con la documentación del fabricante.
Todo el recorrido de una sola medición: del dispositivo de la nevera al mensaje en el teléfono. Más abajo en la página se examina cada uno de esos seis eslabones con más detalle.
Qué se vigila: una cámara, una vitrina, un congelador, una máquina expendedora, una bomba, una unidad de ventilación, una línea de producción. Cada equipo está registrado en el sistema como una ficha propia: qué es, en qué local está, qué dice su ficha técnica y cuándo se le hizo el último mantenimiento.
Los dispositivos que miden. Un sensor es un pequeño dispositivo que mide un valor: temperatura, humedad, presión, corriente, si una puerta está abierta, si hay tensión. Un controlador es el cerebro propio del equipo: en algunos modelos puede comunicar sus lecturas y códigos de error al exterior, y entonces no hacen falta sensores adicionales. Donde no puede, ponemos los nuestros.
Cómo llegan las lecturas a internet. En el local se instala un pequeño dispositivo de comunicación: recoge las mediciones de los sensores y las envía al servidor por cable de internet, wifi o tarjeta SIM. Si internet se cae, las mediciones se acumulan en su memoria y salen cuando vuelve la conexión. El propio silencio del dispositivo cuenta también como alarma.
Donde viven los datos. Un servidor es un ordenador de un centro de datos protegido que funciona las veinticuatro horas. «Nube» significa que no está en su oficina: no hay nada que comprar, refrigerar ni mantener, y al software se llega desde cualquier sitio. El servidor recibe las mediciones, las guarda en el historial, las compara con las normas y convierte una desviación en un evento.
El programa que usted ve. Se abre en el navegador de un ordenador o un teléfono con usuario y contraseña, no hay nada que instalar. En una pantalla: locales, equipos, lecturas actuales y la lista de desviaciones abiertas. Los equipos de distintas marcas se ven todos igual.
El resultado de toda la cadena: un mensaje a un empleado concreto, gráficos y registros para aclarar, informes mensuales y —donde el controlador lo permite— el cambio de los ajustes del equipo directamente desde el panel.
La frecuencia de medición y los límites admitidos se fijan por separado para cada tipo de equipo y no como una cifra única para toda la red. Un congelador, una vitrina refrigerada de platos preparados y una cámara de almacén se diferencian tanto en qué temperatura es normal como en cuánto tiempo se puede superar.
El frío es el ámbito en el que la monitorización se paga más rápido, porque un incumplimiento del régimen no se ve a simple vista. Una puerta entornada durante la noche no la nota nadie, y por la mañana la decisión ya está tomada por usted.
Un ejemplo. Un viernes por la tarde falla el compresor de una cámara de congelación. Durante la noche la mercancía se descongela, el sábado se vuelve a congelar en parte y el lunes el lote se da de baja. Con monitorización, el mensaje sobre la avería llega el viernes a las 21:00 y el asunto termina con una llamada al servicio técnico.
Los equipos también son distintos. Un congelador y una vitrina refrigerada de platos preparados no comparten ni la temperatura admitida, ni la velocidad con que se incumple, ni el coste de un error. Por eso la norma se fija para cada equipo y no una vez para la red, teniendo en cuenta lo que hay dentro.
Qué se puede leer de un equipo de frío:
El conjunto depende del modelo concreto. Si el controlador de fábrica entrega valores y códigos de error, el sistema los lee directamente. Si no puede, se ponen sensores externos de temperatura, puerta y corriente. Qué hay disponible en su equipo se determina en el estudio previo con su documentación y no se promete de antemano.
Por eso las normas se configuran para el tipo de equipo y para la mercancía que hay dentro. Sin eso empiezan a llegar mensajes constantemente, los empleados dejan de abrirlos y el sistema funciona en vano.
Los dispositivos que se emplean en estos grupos son más o menos los mismos. La diferencia está en el régimen admitido, en el coste de un error y en a quién va el mensaje. La estructura es la misma en todos: un equipo, un local, lecturas, normas, eventos, un responsable.
Un punto sin dependiente: sencillamente no hay quien note que una puerta no ha cerrado o que un equipo se ha parado. Los equipos están en una oficina, una fábrica o un coworking y un empleado pasa cada pocos días. El control de temperatura y de puerta es aquí la única forma de enterarse a tiempo de un problema.
Temperaturas muy bajo cero y una gran reserva de frío: una desviación se desarrolla despacio y se descubre con todo un lote estropeado. Se controlan la temperatura, el tiempo fuera de la norma, el funcionamiento del compresor y el descarche.
En la sala de ventas la puerta se abre decenas de veces por turno, así que el régimen se incumple constantemente. Por eso no importa la superación en sí, sino cuánto dura y con qué frecuencia se repite a lo largo del día.
Un volumen grande con varias zonas a temperaturas distintas: un punto de medición no describe la cámara. Se ponen varios sensores y la puerta y la corriente se vigilan aparte: la parada de una cámara significa perder todo el contenido y no una balda.
Varias cámaras y equipos en un local, en turnos y las veinticuatro horas. Hacen falta un reparto de la responsabilidad por zonas, un historial largo y un informe de cumplimiento del régimen de un mes o un trimestre.
Una cadena de puntos con equipos iguales: decenas de vitrinas y arcones en direcciones distintas. El valor está aquí en la comparación: dónde se repiten las desviaciones, qué punto se sale del régimen de forma sistemática y qué equipo toca reparar.
Conservación de materias primas y productos terminados, donde el régimen es un requisito y no una comodidad. Además de los mensajes hace falta poder demostrarlo: un gráfico de cada cámara por periodos y registros de quién reaccionó a las desviaciones y cómo.
Un grupo aparte lo forman los equipos cuyo controlador nunca se diseñó para comunicarse hacia fuera. Se conectan con sensores externos: temperatura, puerta, corriente, consumo. Hay menos datos que de un equipo inteligente, pero lo esencial —régimen, puerta, corriente y compresor— se ve, y un equipo así está en la lista común junto a los demás.
Cada lectura vive en el sistema de dos formas. La primera es el propio valor, que simplemente se guarda en el historial. La segunda es una regla: con qué valor y tras cuántos minutos eso se convierte en una desviación de la que hay que informar a alguien.
Un ejemplo. Una temperatura de −16 °C en una cámara de congelación se guarda siempre, cada minuto. Pero un mensaje sale solo si se mantiene por encima de −18 °C más de quince minutos seguidos.
La lista completa de lo que se lee y se controla:
Una pérdida de conexión no es una nimiedad, sino una alarma en toda regla. Un dispositivo mudo no significa «sin datos», sino «no sabemos nada de ese local». La temperatura de allí puede estar en la norma o puede llevar una hora subiendo. Por eso una pérdida de conexión genera el mismo evento que una alarma de temperatura en lugar de dejar un hueco en el gráfico.
Hay cuatro niveles y del nivel depende a quién molesta el sistema y cómo:
Cada local del sistema tiene un empleado responsable y cada tipo de evento su regla de envío. El sistema no lo manda todo a todos: mira en qué local se produce la desviación, de qué tipo es y qué hora es, y elige el destinatario con esa regla.
Si un empleado no ha asumido un evento en el tiempo previsto, este pasa automáticamente al siguiente de la cadena. De noche, en fines de semana y en festivos el destinatario puede ser otro: eso también se configura de antemano.
El tipo, el equipo y el local, las horas de inicio y fin, las lecturas en el momento en que surgió, a quién y cuándo fue el mensaje, quién lo asumió, qué hizo y cómo terminó. Con eso basta para aclarar un caso un mes después con registros y no con la memoria del turno.
| Condición | Tiempo de espera | Evento |
|---|---|---|
| Temperatura por encima del límite superior del régimen | 15 min | aviso |
| Temperatura por encima del límite | 45 min | alarma |
| Puerta abierta de forma continua | 5 min | aviso |
| La temperatura sube con la puerta cerrada | 10 min | alarma |
| No hay tensión en el equipo | 1 min | alarma |
| El controlador ha devuelto un código de error | al instante | alarma |
| El dispositivo no se comunica | 20 min | alarma |
| El compresor ha funcionado más de lo habitual en 24 horas | 24 horas | para mantenimiento |
Una pantalla del sistema, los valores son ilustrativos. La columna «tiempo de espera» es lo que aguarda el sistema antes de dar la alarma. Sin ella, meter mercancía, un descarche normal y la limpieza de la sala de ventas producirían un flujo de falsas alarmas tras el cual los mensajes dejan de leerse.
Todos los casos siguen el mismo camino: algo cambió en el equipo → el sistema lo registró como evento → un empleado concreto recibió un mensaje. Lo único distinto es la causa y a quién va dirigido.
Qué ocurre: el sensor comunicó que la puerta se abrió y, durante más tiempo del permitido, no comunica que se haya cerrado. Qué hace el sistema: crea un evento «puerta abierta más de la norma» con el número del equipo, la dirección del local y la hora de inicio. Quién se entera: el empleado del punto: el mensaje muestra cuánto lleva ya abierta la puerta. El evento no se cierra hasta que la puerta se cierre.
Qué ocurre: las mediciones muestran una subida sostenida con la puerta cerrada. Qué hace el sistema: registra la desviación con el valor actual y la velocidad de subida. Quién se entera: el responsable del local recibe un aviso: la mercancía todavía está bien y queda tiempo para reaccionar. Si la subida continúa, el aviso se convierte en alarma y va a varios empleados.
Qué ocurre: el dispositivo lleva callado más del intervalo permitido. Qué hace el sistema: crea una alarma: no «sin datos», sino una alarma, porque se desconoce qué ocurre en el local. Quién se entera: los mismos empleados que en una alarma de temperatura, porque las consecuencias pueden ser las mismas.
Qué ocurre: el propio equipo devuelve un código de avería. Qué hace el sistema: registra el código tal cual y lo traduce con la documentación de ese modelo. Quién se entera: el error aparece en la ficha del equipo junto con el historial: cuántas veces ha llegado ya ese mismo código de esa unidad.
Qué ocurre: los indicios de que hace falta descarchar —una señal del controlador, las horas de funcionamiento o la forma del ciclo de temperatura— se salen de la norma. Qué hace el sistema: crea una tarea y no una alarma. Quién se entera: el empleado responsable: la tarea indica de qué equipo se trata, en qué local y para cuándo.
Qué ocurre: no hay tensión en el equipo. Qué hace el sistema: crea una alarma con la hora exacta del corte; la temperatura se sigue registrando mientras el dispositivo de comunicación funciona con su propia batería. Quién se entera: el mensaje sale al instante: en él se basa la decisión de sacar la mercancía y no la de cuándo pedir una reparación.
Una pantalla del sistema, las cifras son ilustrativas. Aquí no importa el mensaje, sino la última línea: el motivo y la duración pasan al historial de esa cámara. Si «puerta del vestíbulo mal cerrada» aparece tres veces más en un mes, saldrá en un informe en lugar de olvidarse junto con el turno.
El sistema hace falta allí donde un equipo funciona sin vigilancia constante y una avería se nota por sus consecuencias. Cambian el conjunto de lecturas y el coste de un error; la estructura del sistema sigue siendo la misma.
Si al menos tres de los cinco puntos coinciden con su situación, la amortización se puede calcular con las pérdidas concretas que ya ha tenido en periodos pasados: mercancía dada de baja, paradas, desplazamientos en balde.
Vending y micromercados: el módulo de telemetría, el software del dispositivo y la recogida de eventos —ventas, errores de la mecánica, temperatura, aperturas de puerta, estado de los módulos de pago y de la conexión— los hemos hecho nosotros y están descritos en la sección sobre de sistemas de autoservicio. Las demás direcciones de la lista son el mismo esquema aplicado a otro tipo de equipo.
Un parque real casi nunca es homogéneo. En un mismo local hay equipos de distintos años y distintos fabricantes: unos tienen un controlador capaz de entregar datos al exterior; otros, uno que no sabe hablar; y otros, nada más allá de la parte de potencia.
De ahí la imagen habitual: cuatro programas para cuatro tipos de equipo, cada uno con su acceso, sus denominaciones de estado y sus avisos. Ninguno da una imagen general del local y comparar dos equipos de marcas distintas entre sí es sencillamente imposible.
Qué hacemos en una situación así:
Qué no afirmamos de antemano. No afirmamos, antes del estudio previo, la compatibilidad con marcas concretas de equipos ni con protocolos industriales. La lista de lo que se lee y de lo que se puede gobernar es el resultado del trabajo con la documentación de su parque y de la comprobación en el sitio, y no una línea de una presentación. Lo único respaldado por un desarrollo terminado es el circuito de vending: un módulo de telemetría propio con controladores MDB y EVA-DTS, descrito en la sección sobre de sistemas de autoservicio.
Cambiar los ajustes de un equipo desde el navegador no siempre es posible. Es una propiedad del equipo y no del software, y hay tres casos:
Esto no se puede sortear con software. Por eso nombramos la lista de órdenes disponibles después del estudio previo y no antes.
La variedad de marcas no se resuelve en el sitio, sino dentro del software: para cada tipo de equipo se escribe un traductor y a partir de ahí todo es igual. Por eso un tipo nuevo se conecta escribiendo un módulo y no rehaciendo el panel, las reglas y los informes.
Controladores capaces de entregar datos al exterior; controladores sin esa capacidad; sensores externos; dispositivos de comunicación. Cada uno tiene su formato, sus unidades de medida, sus denominaciones de estado y su frecuencia de comunicación.
Para cada tipo de fuente se escribe un módulo propio: sabe cómo tomar datos precisamente de ella y los convierte a un formato interno único. El equipo no se cambia: se adapta el software. Ese módulo se llama adaptador.
Unidades de medida iguales, una lista de estados, una descripción igual de un evento. Después de eso una cámara y una bomba se describen en el mismo idioma y las reglas de norma se escriben una vez para todo y no por separado para cada marca.
Una pantalla para todo el parque: locales, equipos, lecturas, desviaciones abiertas, historial, informes y órdenes disponibles. Un empleado trabaja en un programa en lugar de cambiar entre cuatro.
| Fuente de datos | Qué se puede leer | Control | Estado |
|---|---|---|---|
| Un controlador capaz de entregar datos | valores, modos, códigos de error | en parte, según la documentación | en línea |
| Un controlador que no entrega nada | mediante sensores externos | no | en línea |
| Sensores externos en un dispositivo de comunicación | temperatura, puerta, corriente, consumo | no | aviso |
| Un módulo de telemetría de vending | ventas, errores de la mecánica, temperatura, puerta | sí | sin conexión |
Una pantalla del sistema, la composición es ilustrativa. En el panel las cuatro filas se ven igual: la única diferencia queda en las columnas «qué se puede leer» y «control», es decir, en lo que la fuente permite físicamente. Si hay control lo decide el controlador del equipo y no el software.
El panel se abre en el navegador con usuario y contraseña, como una web corriente. No hay nada que instalar y funciona también desde el teléfono.
La primera pantalla. Contadores arriba: cuántos dispositivos están en línea ahora, cuántos callan, cuántas desviaciones hay abiertas en este momento. Debajo, la lista de locales con sus equipos bajo cada uno; cada equipo tiene un estado marcado con color (norma, aviso, alarma, sin conexión) y su valor actual.
La ficha del equipo se abre con un clic en cualquier unidad. Reúne todo lo que se sabe de esa nevera o ese equipo:
Los ajustes se hacen una vez y a partir de ahí funcionan solos: normas y tiempos de espera por tipo de equipo; responsables y reglas de envío de mensajes por local, tipo de evento y hora del día; roles de los empleados —quién ve qué y quién puede hacer qué—; grupos y filtros por local, región y tipo de equipo.
Por qué se lleva el historial. Es cada medición y cada evento, guardados con hora exacta y disponibles en cualquier momento. Hace falta para cinco cosas:
Una palabra aparte sobre los gráficos: están para aclarar y no para los informes. Cuando en la línea de temperatura están marcadas las aperturas de puerta, los arranques del compresor y los cortes de corriente, la causa de una desviación se lee al instante: no hace falta alinear cuatro pantallas distintas.
Si el controlador no acepta órdenes, la sección de control sencillamente no aparece en la ficha. Ahí no hay un botón muerto, para que el turno nunca tenga la impresión de que desde aquí se puede gobernar el equipo.
En un solo local con cinco neveras vale cualquier enfoque, incluso una libreta. La diferencia empieza con cincuenta equipos y con quinientos: la lista deja de caber en una pantalla, los mensajes se funden en un flujo y el empleado responsable de todo deja de responder de algo concreto.
Un ejemplo. De noche se corta la corriente en uno de los puntos. Sin configuración el sistema enviaría treinta alarmas separadas —una por equipo— y todo lo demás se perdería en ese flujo. Con configuración llega un mensaje: este local, corte de corriente, 30 equipos afectados.
Qué cambia al crecer el parque:
Una pantalla del sistema, las cifras son ilustrativas. El orden de las cifras no es casual: en primer lugar no va el tamaño del parque, sino cuántos locales están ahora sin observación. Seis dispositivos mudos son seis puntos de los que no se sabe nada.
Los informes se exportan a un archivo y se pueden generar automáticamente según calendario: por ejemplo, el día uno de cada mes. Para la capa de frío un informe así sirve además como prueba de las condiciones de conservación del periodo.
Los permisos se conceden con la misma estructura: un empleado de un punto ve solo sus equipos, un jefe de departamento todos los locales de su tipo y un operador de la sala de control el resumen de toda la red. Consultar, asumir un evento y el control remoto están separados y no se conceden como un paquete.
Sensores y controladores
Transmisión a la nube
Un panel único
Mensajes e informes
El trabajo principal del sistema se basa en reglas sencillas: este valor durante más de tantos minutos = este mensaje a esta persona. Con eso basta para cubrir las emergencias y por ahí empieza cualquier implantación.
Cuando se han acumulado meses de historial, encima se puede añadir un análisis de datos. No busca un límite incumplido, sino un cambio en el comportamiento habitual de un equipo concreto.
Un ejemplo. Un compresor alcanza su régimen de trabajo normalmente en ocho minutos. Desde hace tres semanas necesita doce. No se ha incumplido ningún límite y por las reglas no habría salido ningún mensaje, pero el equipo va claramente hacia una avería y es mejor darle mantenimiento antes de que se pare un fin de semana.
El límite lo decimos con claridad. La previsión de averías es algo que se hace posible con datos acumulados y no una función que funcione desde el primer día. Necesita un historial no solo de lecturas, sino de las propias averías: sin casos reales no hay con qué entrenar un modelo. Por eso en un proyecto es una etapa aparte, después de un periodo de recogida de datos, y no un punto de la primera entrega.
Un ámbito afín es la implantación de inteligencia artificial en los procesos de negocio, donde el mismo enfoque se aplica a los datos de pedidos, consultas y documentos.
Nada de esto sustituye a las reglas de alarma: las reglas reaccionan en minutos y el análisis trabaja en un horizonte de semanas. Hacen falta ambas capas y se implantan exactamente en ese orden.
Las etapas van exactamente en este orden. Saltarse el estudio previo es el motivo más frecuente de que un sistema acabe construido alrededor de equipos que no entregan los datos necesarios.
Un inventario del parque: modelos, controladores, documentación, qué se puede leer físicamente de cada equipo y si hay internet en los locales. El resultado es una lista de lo que está disponible enseguida y de lo que habrá que cubrir con sensores externos.
Un local y unos pocos equipos: instalación, comprobación del intercambio con un controlador real, ajuste de las normas y los tiempos de espera al comportamiento real del equipo y no a la documentación.
Quién responde de qué locales, qué eventos van a quién, qué se considera alarma y qué es solo una nota. Aquí se configuran también el escalado y la unificación de eventos iguales; de lo contrario el flujo de mensajes devalúa el sistema en un mes.
Los locales restantes siguen el patrón probado y los tipos de equipo nuevos llegan como módulos de intercambio propios. A partir de ahí se acumula historial y aparecen los informes por periodos y el análisis de datos.
Cuéntenos qué equipos hay en sus locales, cuántos son y de qué problemas se entera hoy solo por sus consecuencias. Le diremos qué se puede leer realmente de ellos, dónde harán falta sensores externos y por dónde tiene sentido empezar el piloto.
