¿Por qué Rela AI?
Los 4 diferenciadores únicos del Plant OS de Rela frente a Augury, Tractian, SafetyChain, Tulip y CMMS clásicos.
¿Por qué Rela AI?
Rela AI no es otro CMMS, ni una plataforma IoT genérica, ni una app de HACCP digitalizado. Es un Plant OS para PYMES food — un sistema operativo conversacional para panaderías, lácteos y cárnicos pequeños y medianos.
Esta página documenta los cuatro diferenciadores que hacen la categoría defendible. Cada uno responde a una pregunta concreta: "¿qué hace Rela que los competidores no pueden hacer, y por qué no pueden simplemente copiarlo?".
Rela AI no es un dashboard que espera a que alguien mire los datos. Es un agente de planta que escucha tu PLC, cumple HACCP en tiempo real, sostiene la cadena de frío y orquesta a tu equipo por WhatsApp — todo sobre un mismo grafo de activos y procesos.
Los cuatro diferenciadores:
- Lectura de PLCs existentes vía VPN — sin hardware propio
- Bootstrap sin historial — extrusora desde el primer mes
- Capa agéntica conversacional — WhatsApp y email como UI primaria
- Asset / process graph compartido — siete módulos, una sola realidad
1. Lectura de PLCs existentes vía VPN — sin hardware propio
El problema
La PYME food típica ya tiene controladores en planta: PLCs Siemens S7, Schneider Modicon, Rockwell ControlLogix, Carel, WAGO, autómatas de los OEMs de cámaras y túneles. Cada uno expone datos por Modbus TCP, OPC UA, S7, EtherNet/IP, MQTT o protocolos propietarios. El operador ya tiene el HMI del fabricante. El problema no es falta de datos: es que esos datos viven en silos y nadie los lee fuera del HMI.
Cómo lo resuelve Rela
Rela conecta una VPN industrial a la red de la planta y suscribe sus listeners a los PLCs existentes — Modbus TCP en pull, OPC UA con suscripción nativa, MQTT por broker (incluyendo Sparkplug B y OPC UA Pub/Sub), S7 y EtherNet/IP por sondeo half-duplex. Cero hardware propio: ningún sensor que comprar, ningún edge gateway que mantener, ningún mantenimiento extra para tu equipo. Una sola VPN sirve incluso para múltiples marcas de controladores en la misma planta.
| Rela AI | Augury / Tractian | Plataforma IoT genérica | |
|---|---|---|---|
| Hardware adicional | Cero — solo VPN | Sensor de vibración por activo | Edge gateway + sensores |
| Dependencia del fabricante | Ninguna — habla a tu PLC actual | Vendor lock-in del sensor | Vendor lock-in del gateway |
| Tiempo a primer dato | Horas tras VPN arriba | Semanas (instalar sensores) | Semanas (configurar gateway) |
| Cobertura de variables | Cualquier tag del PLC | Solo lo que mide el sensor | Lo que el gateway expone |
Augury y Tractian son sensor-first: necesitan vender e instalar sus acelerómetros para empezar. Eso los excluye de cubrir variables de proceso (temperatura del horno, presión de la pasteurizadora, humedad de la cámara de fermentación) que ya están en el PLC.
Prueba
- Caso COLIP — flota de cámaras de fermentación Carel por Modbus: 35 cámaras de cuatro marcas distintas, una sola VPN, lectura nativa Modbus sin sensores adicionales.
- Multi-marca Modbus por VPN única: Schneider + Carel + WAGO en la misma planta de panadería, sin tocar el HMI original.
- Multi-máquina por un solo túnel: arquitectura de la VPN + listener manager.
Competencia que falla aquí
- Augury y Tractian: requieren su sensor; no leen el PLC original.
- GE Predix, Siemens MindSphere: requieren su edge gateway o stack OPC UA específico; no escalan a PYMES.
- CMMS clásicos (SAP PM, Maximo, Fracttal): no leen PLCs, dependen de captura manual.
2. Bootstrap sin historial — extrusora desde el primer mes
El problema
El estándar de mantenimiento predictivo industrial dice que necesitas tres a seis meses de historial limpio para entrenar un modelo. Esto descalifica a toda planta nueva, a todo equipo recién instalado, a todo activo del que el fabricante anterior nunca exportó datos. La PYME food rara vez tiene historial limpio: lo que tiene son tres años de paradas mal etiquetadas en una planilla.
Cómo lo resuelve Rela
Rela arranca con un modo bootstrap que combina:
- Reglas físicas del manual del activo (RUL ceiling por temperatura, vibración límite, corriente nominal).
- Detección de cambio puro (Page-Hinkley sobre energía y vibración) que no requiere baseline aprendida.
- Z-score con baseline parcial que se va calibrando turno a turno.
- Severidad canónica (
info<warning<high<critical) — la primera semana solo se publican alertaswarningy superiores; el operador califica cada una y eso retroalimenta la baseline.
A los 30 días un activo nuevo ya tiene AHI y RUL fiables. A los 90 días el modelo es indistinguible del que tendría un activo con dos años de historial.
| Rela AI | Augury | Plataforma genérica de ML | |
|---|---|---|---|
| Tiempo a primera alerta útil | 1–4 semanas | 3–6 meses | 6+ meses |
| Requiere historial limpio | No | Sí | Sí |
| Reglas físicas del manual | Sí, integradas en bootstrap | No | No |
| Calibración con feedback humano | Sí, por severidad calificada | Limitada | Manual |
Prueba
- Bootstrap sin historial — extrusora: extrusora nueva con cero datos, primera alerta útil al día 11.
- Configuración de RUL ceilings y jerarquía de reglas: documentación técnica del modo bootstrap.
- Anomaly detection — ML ensemble: cómo el ensemble combina Page-Hinkley + z-score sin baseline completa.
Competencia que falla aquí
- Augury: cold start documentado de 90–180 días por activo.
- Tractian: igual, sensor-first y baseline necesaria.
- CMMS: no hace mantenimiento predictivo, solo preventivo programado.
3. Capa agéntica conversacional — WhatsApp y email como UI primaria
El problema
El operador de planta de una PYME food no tiene laptop en la línea. Tiene un teléfono, las manos sucias y 18 segundos para decidir qué hacer cuando el horno HR-3 escupe humo. SafetyChain, Tulip, Augury y los CMMS clásicos asumen que la UI primaria es una dashboard. Para el operador, una dashboard es un lugar al que casi nunca va.
Cómo lo resuelve Rela
La UI primaria de Rela es WhatsApp. El operador habla con un agente conversacional que entiende lenguaje natural, accede al estado del PLC en tiempo real, recomienda acciones y abre OTs para que el equipo apruebe. El mismo agente atiende email, reportes en PDF, calendarios y Postmark cuando el contexto lo pide.
Las herramientas del agente cubren cuatro categorías:
- Consulta de datos — busca un activo, un lote, un técnico, un CCP, una OT.
- Acciones internas — genera reportes PDF, pre-asigna tareas, redacta mensajes, localiza personal.
- Conexiones externas — llama APIs REST, suscribe a topics MQTT, lee OPC UA, sincroniza con CMMS o ERP.
- Aprobación humana — toda acción que toca al equipo o a un equipo necesita aprobación antes de ejecutarse.
| Rela AI | SafetyChain / Tulip | Augury / Tractian | CMMS clásico | |
|---|---|---|---|---|
| UI primaria | WhatsApp + email | Dashboard web + app móvil | App móvil propietaria | Escritorio + login VPN |
| Lenguaje natural | Sí, agente conversacional | No (formularios) | No (lista de alertas) | No (formularios) |
| Capacitación | Mínima — el operador ya usa WhatsApp | Sesiones formales | Sesiones formales | Curso de licencia |
| Acceso del técnico externo | Compartir teléfono | Crear usuario, app, login | Crear usuario, app, login | Licencia + VPN |
Prueba
- Agente WhatsApp — creación y creación de un agente de email.
- Inbox unificado de alertas: cómo el agente consolida alertas de múltiples detectores en un solo hilo de conversación.
- Caso unificado — alert inbox: un E2E con tres detectores disparando, un solo mensaje en WhatsApp, un solo técnico asignado.
Competencia que falla aquí
- SafetyChain: dashboard-first, no resuelve el problema del operador en línea.
- Tulip: apps móviles configurables, pero requieren que el operador abra la app — sin agente conversacional, sin WhatsApp.
- Augury / Tractian: notifican por su app o por email, sin un agente que pueda responder a una pregunta del operador.
- CMMS clásico: cero capa conversacional.
4. Asset / process graph compartido — siete módulos, una sola realidad
El problema
La PYME food que intenta digitalizarse termina con cinco productos distintos: un CMMS para mantenimiento, una app de SafetyChain para HACCP, la app del fabricante de la cámara para cadena de frío, una hoja Excel para OEE, una carpeta de papel para LOTO. Cada producto tiene su propia versión del activo "horno HR-3". Reconciliar entre ellos consume horas semanales y aun así nunca da la misma respuesta.
Cómo lo resuelve Rela
Las siete capas de Rela — agente conversacional, HACCP, cadena de frío, OEE, mantenimiento, LOTO, datos e integraciones — comparten un mismo asset / process graph. El horno HR-3 es un solo nodo del grafo, con aristas hacia su CCP HACCP, hacia su cadena de frío downstream, hacia su línea OEE, hacia sus OTs de mantenimiento y hacia sus puntos LOTO.
Esto no es solo "buen diseño de datos": es la única forma de que el agente WhatsApp, al recibir "se paró el horno HR-3", sepa simultáneamente qué CCP está en riesgo, qué pérdida de OEE acumula la línea 2, qué OT preventiva estaba programada y qué LOTO debe ejecutarse antes de abrir la cámara.
| Rela AI | Best-of-breed (CMMS + SafetyChain + cold-chain + OEE) | Tulip | |
|---|---|---|---|
| Modelo de activo | Único, compartido entre 7 capas | 4 modelos distintos, reconciliados a mano | Configurable, pero por app |
| Genealogía cross-módulo | Nativa | Imposible sin integraciones custom | Limitada |
| Tiempo para responder "qué pasa con HR-3" | Inmediato, en WhatsApp | Horas, abriendo 4 herramientas | Variable |
| Costo de licencia agregada | Una sola | Suma de 4 licencias | Una, pero genérica |
Prueba
- Plant OS — qué es y por qué tu planta lo necesita: diagrama del asset graph con las 7 capas y argumentación completa.
- Arquitectura: modelo de datos compartido y cómo se expone a los agentes.
- Caso unificado — alert inbox: ejemplo concreto de cómo una alerta cruzada (HACCP + mantenimiento) se resuelve por la misma vía.
Competencia que falla aquí
- CMMS + SafetyChain + cold-chain app + OEE Excel: cuatro herramientas, cuatro modelos de activo, cero respuesta unificada.
- Tulip: una sola plataforma, pero genérica — no hay HACCP profundo ni asset graph food-specific.
- Augury / Tractian: solo mantenimiento; ni HACCP ni cadena de frío entran en su grafo.
Resumen
| Diferenciador | Lo que hace Rela | Lo que NO hace la competencia |
|---|---|---|
| 1. Lectura de PLCs vía VPN | Lee tu PLC actual sin hardware propio | Augury / Tractian: necesitan su sensor |
| 2. Bootstrap sin historial | Primera alerta útil en 1–4 semanas | Augury: 90–180 días de cold start |
| 3. Agente WhatsApp / email | Conversación, no dashboard | SafetyChain / Tulip: dashboard-first |
| 4. Asset graph compartido | Una sola realidad para 7 capas | Best-of-breed: 4–5 herramientas desconectadas |
La combinación es lo importante. Cualquier competidor podría copiar uno de los cuatro; copiar los cuatro a la vez exige ser vertical food + lectura de PLC + agéntico + compound desde el primer día.