Tormenta de alertas del RCS: qué alarmas de AMR silenciar — y cuáles no ignorar jamás

Opera un almacén con 50 AMR y tu RCS puede escupir fácilmente miles de alertas al día. Es como instalar 20 apps en tu teléfono, cada una enviando 10 notificaciones por hora — en una semana, el operador de la sala de control aprende a descartarlas todas por reflejo. Y ahí es cuando una falla real se ahoga en el ruido, sin que nadie la vea.

Esto es la fatiga de alertas. Los hospitales lo descubrieron hace una década. La automatización de almacenes es lo siguiente.

Por qué explotan las alertas del RCS

El RCS es el policía de tráfico y el despachador de la flota — rutas, tareas, carga. Piénsalo así: cada AMR lleva docenas de sensores — LiDAR, parachoques de seguridad, encoders, el BMS de la batería, radios WiFi — cada uno con su propio umbral, cada uno disparando eventos hacia arriba. Cincuenta robots por docenas de sensores por 24 horas: esa es tu materia prima.

La inundación suele venir de tres lugares.

Primero, la capa del robot. Eventos que el propio AMR genera: oscilaciones de temperatura de la batería, desaceleraciones puntuales por obstáculos, relocalización, itinerancia WiFi. Alto volumen, y la gran mayoría se autocorrige.

Segundo, la capa de la flota. Eventos que genera el RCS: tiempos de espera de tareas agotados, bloqueos de ruta, congestión de zonas, esperas en la cola de carga. Bajo volumen, pero cada uno toca directamente el rendimiento.

Tercero — y lo diré sin rodeos — el instinto del integrador de cubrirse las espaldas. Muchos proyectos salen con reglas de alerta configuradas para la responsabilidad legal en lugar de la operación: "avísame cuando la señal WiFi baje de -70 dBm". Esa alerta no sirve para nada salvo para entrenar a los operadores a quedarse insensibles. No tengo paciencia para los pseudo-requisitos: más alertas no es más diligencia. Mil alertas que nadie lee es lo mismo que cero.

Triaje: las alarmas de AMR tienen tres niveles. Más que eso es teatro

Tres niveles: P0, P1, P2. Una línea dura los separa: si nadie mira esta alerta, ¿se detiene la línea en 30 minutos? Sí va a P0. No, pero el rendimiento sufre, va a P1. Ninguna de las dos, va a P2, directo al registro. Tosco, pero funciona.

Dos historias de campo.

A finales de 2024, antes del pico del Día del Soltero, un almacén de comercio electrónico en el este de China operaba 60 AMR con la política de alertas del RCS en valores de fábrica: todo activado, más de 4,000 alertas al día. El operador me contó después que había aprendido a "mirar la ventana emergente con el rabillo del ojo y cerrarla". Entonces el BMS de un robot marcó sobretemperatura de batería — un verdadero P0 — enterrado bajo miles de entradas de "itinerancia WiFi" y "desaceleración por obstáculo". Más de cuarenta minutos después, una ronda de piso encontró el robot muerto en el pasillo principal, media línea de picking caída. La autopsia cupo en una frase: no es que no hubiera alertas; había tantas que era lo mismo que ninguna.

El contraejemplo está en el sur: un almacén 3C con 40 AMR pasó su primer mes enviando ventanas emergentes por "relocalización exitosa" — eventos autocorregidos. Setecientas de sus 800 alertas diarias eran buenas noticias. Nueva regla: lo autocorregido va al registro; solo la recuperación fallida escala. Las ventanas emergentes bajaron de 800 a unas 60 al día, y el operador volvió a mirar la pantalla. El problema nunca fue "no hay suficientes alertas".

Silenciar no es borrar: tres trampas en el ajuste de alertas

Niveles fijados. Ahora viene el trabajo manual de silenciar reglas y ajustar umbrales — y tres trampas que he visto tragarse al menos un proyecto cada una.

Trampa 1: silenciar y olvidar. Silenciar es una decisión de riesgo. Necesita un registro de cambios: quién lo aprobó, por qué y cuándo vence. Es como quitarle la batería a un detector de humo sin avisar a la administración del edificio — cuando hay un incendio, la primera pregunta es "quién quitó la batería". Mi regla: cada silencio va a un registro con un aprobador y una fecha de revisión; los silencios vencidos se restauran automáticamente, forzando una reevaluación.

Trampa 2: copiar umbrales del almacén de otro. Planitud del piso, cobertura WiFi, densidad de estanterías — no hay dos sitios iguales. "Alertar cuando las desaceleraciones por obstáculos superen 10 por minuto" puede ser perfecto en el Sitio A y una máquina de falsas alarmas en el Sitio B. La secuencia correcta: corre las primeras dos semanas con todo registrando pero nada notificando, y luego fija los umbrales con tus propios datos. Observa primero, legisla después — no al revés.

Trampa 3: deduplicación demasiado agresiva. Algunos equipos fusionan "fallo de navegación" y "tiempo de tarea agotado" en una sola "anomalía de AMR" para reducir el conteo, y luego lloran al solucionar problemas. Solo deduplica repeticiones de la misma causa, en el mismo robot, con minutos de diferencia. Nunca fusiones causas distintas — deduplicas el ruido, no la información.

Antes de silenciar una sola alerta, pásala por esta matriz de decisión:

La celda superior derecha merece una palabra: una alerta a la vez frecuente y grave significa que tu sistema mismo está enfermo. Ajustar alertas ahí es darle analgésicos a un paciente crítico.

Y una idea contraintuitiva para cerrar la parte técnica: la gente asume que "cuanto más silencias, más peligroso el sistema". Al revés. Silenciar no es peligroso; lo peligroso es silenciar cosas que nadie sabe que están silenciadas. Un sistema con todo en P0 y un sistema sin alertas mueren exactamente igual — nadie está mirando.

¿Valió la pena el dinero? Un número te lo dice: el tiempo promedio desde que se dispara una alerta P0 hasta que un humano empieza a trabajarla. Bájalo de 40 minutos a 5, y tu esfuerzo de gobernanza de alertas se pagó solo. Si no se mueve, todo lo anterior — el triaje, el silenciamiento, la deduplicación — fue teatro.

Por Da Liu, Ingeniero de automatización

Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.