Panadería italiana — flota de cámaras de fermentación

Una panadería industrial italiana de tamaño medio quiere monitorear sus 3 cámaras de fermentación bajo un único túnel VPN. Los 3 PLC son Carel pCO5+ con tarjeta pCOWeb (la combinación dominante en cámaras de lievitazione fabricadas en Italia). El objetivo: AHI por cámara, alarmas en WhatsApp cuando temperatura/humedad salen de rango, y orden de trabajo automática al técnico de turno.

Resumen ejecutivo

El cambio de juego: un solo .conf de WireGuard cubre las 3 cámaras. Cada PLC sigue siendo un activo independiente en Rela con su propio AHI, su propia ventana de mantenimiento y su propio responsable, pero la red la configura el cliente una sola vez.

¿Para qué sirve?

• Vigilar 3 cámaras de fermentación distintas (líneas A, B, C) sin saturar al operador.
• Capturar el ciclo completo de cada cámara: setpoint vs. medida real de temperatura, humedad, fase activa, puerta abierta.
• Asociar cada lectura al activo correcto (cámara A, B, C) para que el AHI y el Remaining Useful Life sean por equipo, no agregados.
• Disparar alertas y órdenes de trabajo distintas según qué cámara falla, sin reglas duplicadas.

Antes de empezar — por qué configurás vos el peer

Tu equipo IT puede sugerir "te damos credenciales de nuestra VPN corporativa, conéctense con eso". La respuesta es firme: no.

Tres razones críticas (las 9 completas en Por qué un túnel dedicado):

1. Mínimo privilegio: tu VPN corporativa abre toda tu red (ERP, mail, SharePoint, OT). Rela solo necesita la subnet del PLC. Una brecha del lado de Rela afecta una subnet OT, no toda la empresa.
2. Revocación en segundos: borrás el peer en tu router cuando quieras, sin tickets ni coordinar con nosotros. La llave privada vive en tu hardware y no sale nunca.
3. Compliance (IEC 62443, NIST SP 800-82, SOC 2, ISO 27001): todas exigen separación IT/OT vía túnel dedicado. Compartir credenciales corporativas es findable directo en cualquier auditoría.

Compartir credenciales sale del modelo self-service y escala a deployment custom enterprise (precio diferente, túnel IPsec site-to-site dedicado).

¿Cómo funciona?

flowchart LR
  PLC_A["Carel pCO5 plus<br/>Cámara Linea A<br/>192.168.10.50"] --> R[("Router del cliente<br/>WireGuard + DNAT")]
  PLC_B["Carel pCO5 plus<br/>Cámara Linea B<br/>192.168.10.51"] --> R
  PLC_C["Carel pCO5 plus<br/>Cámara Linea C<br/>192.168.10.52"] --> R
  R -- "WireGuard tunnel" --> CONC[("Concentrador<br/>Rela VPN")]
  CONC --> WORKER[("Cloud Run worker<br/>3 modbus_listener tasks")]
  WORKER --> PIPE[("Pipeline predictivo<br/>anomaly + health + RUL")]
  PIPE --> AST_A[Asset Linea A]
  PIPE --> AST_B[Asset Linea B]
  PIPE --> AST_C[Asset Linea C]

El flujo en 1 frase: cada PLC habla Modbus TCP en su LAN; el router del cliente reescribe direcciones VPN a direcciones LAN; el worker de Rela polea los registros como si las 3 cámaras estuvieran en su misma red; el pipeline atribuye cada evento al activo correcto.

Parámetros / Configuración

Mapeo Modbus típico de Carel pCO5+ (firmware de fermentación estándar; el OEM puede variar las direcciones — siempre confirmar con manual del fabricante):

Direcciones de red (ejemplo realista del setup):

¿Cómo usarlo?

Paso 1 — Crear el túnel VPN (una sola vez)

1. Sidebar -> Settings -> Connectivity.
2. Ingresar etiqueta: Panadería - Producción.
3. Click Crear peer. El backend asigna 10.200.7.0/24, IP del cliente 10.200.7.2.
4. Descargar .conf de WireGuard. Importarlo en el router del cliente (Mikrotik, pfSense, OPNsense — cualquiera con WireGuard nativo).

Paso 2 — DNAT de las 3 cámaras en el router

El cliente abre el router y agrega 3 reglas de NAT (en Mikrotik se ven así):

/ip firewall nat
add chain=dstnat dst-address=10.200.7.50 dst-port=502 \
    protocol=tcp action=dst-nat to-addresses=192.168.10.50 to-ports=502
add chain=dstnat dst-address=10.200.7.51 dst-port=502 \
    protocol=tcp action=dst-nat to-addresses=192.168.10.51 to-ports=502
add chain=dstnat dst-address=10.200.7.52 dst-port=502 \
    protocol=tcp action=dst-nat to-addresses=192.168.10.52 to-ports=502

/ip firewall filter
add action=accept chain=forward in-interface=rela-vpn src-address=10.200.0.0/16

Por qué importa: el worker de Rela "ve" las cámaras con direcciones 10.200.7.50/.51/.52. El router traduce esa dirección a la IP real del PLC en LAN. Si saltás este paso, las 3 cámaras quedan inalcanzables aunque el túnel funcione.

Paso 3 — Crear los 3 activos en Rela

Sidebar -> Activos -> + Nuevo. Repetir 3 veces:

Paso 4 — Crear el agente de máquina

Sidebar -> Alarmas -> Agentes de máquina -> + Nuevo.

Nombre:                   Vigilante Lievitazione
Modelo:                   gemini-3.1-pro-preview
Auto-assign task:         si  -> Departamento "Produzione"
Auto-notify WhatsApp:     si  -> Numero del jefe de planta
Escalation:               si
  Step 1: 5 min  -> Operario de turno
  Step 2: 15 min -> Jefe de planta
  Step 3: 30 min -> Manager
RCA enabled:              si  -> Min severity: critical

Un solo agente cubre las 3 cámaras: las reglas pueden filtrar después por source_id si querés routing distinto por cámara.

Paso 5 — Crear los 3 sources Modbus

Sidebar -> Alarmas -> Fuentes -> + Nueva fuente. Repetir 3 veces, una por cámara:

Source ID:                lievitazione-linea-a    (.../-b, .../-c)
Agent:                    Vigilante Lievitazione
Protocol:                 Modbus TCP
Modbus host:              10.200.7.50             (.51 para B, .52 para C)
Modbus port:              502
Unit ID:                  1
Connect timeout:          5 s

Registros:
  - temperatura_medida   addr=2  type=float32  fc=3   unit="°C"
                         emit=data_change deadband=0.5
  - humedad_medida       addr=4  type=float32  fc=3   unit="%"
                         emit=data_change deadband=2.0
  - fase_ciclo           addr=10 type=uint16   fc=3
                         emit=data_change deadband=0
  - puerta_abierta       addr=1  type=bool     fc=2
                         emit=bit_flip
  - alarma_sonda_t       addr=20 type=bool     fc=2
                         emit=bit_flip

Min interval:             10 s
Min severity:             warning

Paso 6 — Vincular cada source a su activo

Sidebar -> Activos -> click en Cámara Lievitazione Linea A -> Editar -> campo event_source_ids: agregar lievitazione-linea-a. Guardar. Repetir para B y C.

Por qué importa: sin este link, los eventos vienen del PLC pero el AHI, el RUL y los KPIs no saben a qué cámara atribuirlos. Con el link, todo el pipeline predictivo funciona por cámara individual.

Paso 7 — Verificar que las 3 conexiones están vivas

Volver a Alarmas -> Fuentes. Las 3 filas deben mostrar puntito verde parpadeante. En menos de 60 segundos deben empezar a aparecer eventos en Alarmas -> Live con event_type=DATA_CHANGE y los registros decodificados (temperatura, humedad, fase).

Si una cámara queda en rojo, ver el Troubleshooting.

Casos de uso reales

Alarma de puerta olvidada

Operador deja la puerta de la Cámara B abierta al final del turno noche. A los 30 segundos:

1. Carel pCO5+ flippea coil 1 a 1.
2. Worker recibe bit_flip -> MachineEventRequest{event_type: "DATA_CHANGE", metadata: {puerta_abierta: true}}.
3. Pipeline procesa, agente Vigilante Lievitazione genera task "Cerrar puerta cámara B" asignada a operario de turno.
4. WhatsApp llega al operario en menos de 1 minuto.
5. Si no se cierra en 5 min, escala al jefe de planta.

Deriva de sonda de humedad

Cámara A muestra humedad 80% reportada pero el setpoint era 78%. El detector de anomalías ML (IsolationForest + LOF) aprende el patrón normal en 7 días. Cuando la sonda empieza a desviarse +5% sostenidos, antes de que la masa se vea afectada, el AHI baja de A a B y el RUL sugiere recalibración en menos de 2 semanas. Task PM generada automáticamente.

Fallo eléctrico parcial

Corte de luz en la Linea C apaga el ventilador. Coil de alarma sonda no dispara (la sonda funciona), pero la temperatura empieza a subir 0.3 °C/min. Reglas determinísticas detectan temperatura_medida > setpoint + 3°C durante 3 muestras consecutivas (recurrence config) y disparan severity critical. Escalation a jefe de planta directo.

Limitaciones y supuestos

• Direcciones Modbus dependen del firmware OEM. El mapping de la tabla es el patrón Carel estándar, pero cada fabricante de cámara (Climaset, Forni Fiorini, los OEM italianos típicos) personaliza el firmware. Pedir el manual al integrador antes de configurar los registros.
• Las 3 cámaras tienen que estar en la misma LAN del cliente. Si están en sucursales distintas, son 3 túneles VPN distintos (un peer por sitio). El modelo "1 túnel = 1 sitio físico" no se rompe.
• Modbus TCP es plaintext. Las credenciales de Modbus no existen como tal (no hay password) — la seguridad la da el túnel WireGuard. Por eso es mandatorio que el firewall del router solo acepte tráfico desde 10.200.0.0/16 hacia los PLCs, no desde internet abierto.
• El listener corre en un solo worker. Si el worker se reinicia (deploy o crash), los 3 listeners se reinician juntos con backoff exponencial. El circuit breaker abre 5 minutos si hay fallos sostenidos. Pérdida típica de datos en un restart: 30-60 segundos.

Troubleshooting

Beneficios clave

• Setup VPN único: 1 cliente, 1 router, 1 .conf — no importa cuántas cámaras tenga.
• Trazabilidad por activo: AHI, RUL, KPIs y tasks se calculan por cámara individual.
• Mantenimiento predictivo desde el día 7: el modelo aprende patrones normales en una semana de datos y empieza a detectar deriva.
• Escalation diferenciada: una cámara crítica (Linea A, masa madre) puede tener escalation más agresivo que una cámara de respaldo.
• Cero hardware extra: no se vende ni se instala gateway, sensor, ni datalogger. Reusa el PLC y la red existentes.

Ver también

• Flota heterogénea — 3 marcas de PLC, un solo túnel VPN — cuando las cámaras son de marcas distintas.
• Por qué un túnel dedicado — las 9 razones por las que no compartimos la VPN corporativa del cliente.