Protocolos Industriales Nativos

Además de HTTP / MQTT / OPC UA, Rela AI habla de forma nativa los tres protocolos más extendidos en piso de planta: Modbus TCP, S7comm (Siemens) y EtherNet/IP (CIP, Allen-Bradley). Eso significa que el agente puede leer variables y ejecutar escrituras sobre PLCs sin depender de un gateway intermediario que traduzca a HTTP o MQTT.

¿Para qué sirve?

Gran parte del parque industrial instalado no tiene servidor OPC UA. Un PLC Siemens S7-1200 o un PLC Allen-Bradley de una línea legacy hablan sus protocolos nativos. Hasta hace poco, la única forma de integrarlos con un asistente era instalar un gateway (HMS Anybus, Moxa, etc.) o un servidor OPC UA intermedio. Ahora:

• El agente lee directamente los registros / data blocks / tags.
• El agente escribe directamente a coils, holding registers, DB words, tags CIP (half-duplex completo).
• El listener de eventos industriales ingesta cambios de valor y los convierte en MachineEvent sin pasar por una URL HTTP.

Esto reduce tres cosas a la vez: costo de integración (sin gateway), latencia (un hop menos), y superficie de fallo (menos sistemas intermedios).

¿Cómo funciona?

flowchart LR
  PLC[PLC / SCADA] -->|Modbus TCP / S7 / CIP / OPC UA| L[Listener persistente<br/>worker WORKER_MODE=true]
  L --> FM[Field mapping<br/>+ normalización]
  FM --> P[Pipeline predictivo<br/>anomaly / energy / prognostics]
  A[Agente IA] -->|dispatcher síncrono| PLC

Dos caminos: los listeners persistentes del worker leen continuamente y publican eventos al pipeline; los dispatchers síncronos permiten a las herramientas del agente escribir de vuelta al PLC. Cada protocolo trae su librería canónica (pymodbus 3.8+, snap7, pycomm3, asyncua) y sus gotchas (ver el CLAUDE.md de relaai-api para los kwargs específicos).

Protocolos soportados

Modbus TCP

Lectura (listener)

Para ingesta continua, se configura una fuente de tipo modbus apuntando a la IP:puerto del PLC con una lista de registros a polear.

protocol: modbus
modbus_host: 10.10.2.15
modbus_port: 502
modbus_unit_id: 1
poll_interval_s: 5
registers:
  - address: 40001
    count: 2
    register_type: holding
    field_name: tank_level
  - address: 0
    count: 1
    register_type: discrete
    field_name: pump_running

Tipos soportados en register_type: holding, input, coil, discrete.

Escritura (tool action)

Se configura una tool de tipo action con protocolo modbus. Los parámetros (address, value) pueden venir del payload del agente o pre-configurarse.

tool_type: action
config:
  protocol: modbus
  modbus_host: 10.10.2.15
  modbus_port: 502
  modbus_unit_id: 1
  modbus_operation: holding   # o "coil"
action_defaults:
  address: 40100

El dispatcher valida modbus_host, address y value, abre conexión async, ejecuta write_register o write_coil (kwarg device_id, API pymodbus 3.8+), cierra, y retorna {success, written, address, value, type, duration_ms}.

S7comm (Siemens)

Lectura (listener)

Fuente de tipo s7:

protocol: s7
s7_host: 10.10.2.40
s7_rack: 0
s7_slot: 1
poll_interval_s: 10
variables:
  - area: DB
    db_number: 20
    offset: 0
    data_type: real
    field_name: pressure
  - area: M
    offset: 100
    bit: 0
    data_type: bool
    field_name: alarm_bit

Áreas soportadas: DB (Data Block), M (marker), I (inputs), Q (outputs).

Escritura (tool action)

tool_type: action
config:
  protocol: s7
  s7_host: 10.10.2.40
  s7_rack: 0
  s7_slot: 1
action_defaults:
  db_number: 20
  offset: 0
  data_type: real

El dispatcher lanza snap7.util para codificar el valor según data_type (int, dint, real, bool, byte, word, dword, string), abre conexión, escribe al DB, y cierra. Retorna {success, written, db, offset, value, type}.

Tipos codificados por el dispatcher (helper _s7_encode_value):

EtherNet/IP (CIP)

Lectura (listener)

Fuente de tipo ethernet_ip (Allen-Bradley Logix family):

protocol: ethernet_ip
cip_host: 10.10.3.22
poll_interval_s: 5
tags:
  - tag_name: Program:MainProgram.Temperature
    field_name: temperature
  - tag_name: TankLevelPercent
    field_name: tank_level

Escritura (tool action)

tool_type: action
config:
  protocol: ethernet_ip
  cip_host: 10.10.3.22

El agente proporciona tag_name + value. El dispatcher usa pycomm3.LogixDriver para escribir; si el tag no existe o el tipo no coincide, pycomm3 retorna error y la tool responde {success: false, error}.

Fuentes OPC UA Reverse Connect

Para PLCs detrás de firewalls estrictos que no permiten conexiones entrantes, Rela AI soporta OPC UA Reverse Connect: el PLC inicia la conexión TCP hacia el servidor, invirtiendo el modelo habitual. Configurar como fuente de tipo opcua_reverse con opcua_reverse_listen_port y opcionalmente certificados aceptados.

Consideraciones de seguridad

• Isolation de red: los listeners y dispatchers industriales deben correr en un worker con acceso a la VLAN industrial, separado del plano de gestión del SaaS.
• Permisos de escritura: pre-configura address / db_number / tag_name vía action_defaults cuando sea posible, para que el agente no pueda apuntar a registros arbitrarios.
• Confirmación humana: agentes con acciones de escritura deben incluir "confirma antes de ejecutar" en el prompt.
• Rate limiting: evita tools que permitan escrituras masivas en un solo turno del agente.
• Auditoría: cada escritura se loguea con host, address/db/tag, value, actor (agente) y duration_ms. Ver Audit Trail.

Listeners persistentes y orquestación

Los protocolos MQTT, OPC UA, Modbus, S7 y EtherNet/IP requieren una conexión persistente (no una llamada puntual como HTTP). Rela AI los gestiona en un servicio separado (rela-ai-worker en Cloud Run) que:

• Escanea todas las fuentes habilitadas al arranque.
• Arranca un asyncio.Task por fuente.
• Implementa reconexión automática con backoff exponencial (1s → 60s).
• Publica estado de conexión (connecting, connected, disconnected, error) en tiempo real vía Ably.
• Detiene y reinicia listeners automáticamente cuando una fuente se crea, actualiza o elimina.

La API web (servicio principal) no ejecuta listeners; solo el worker. Esto evita que escalar el frontend arranque N conexiones paralelas al mismo PLC.

Testing en el dashboard

Antes de activar una fuente o una tool de escritura, desde la pantalla de configuración:

1. Probar conexión — abre un socket de prueba al host/puerto y valida credenciales.
2. Probar lectura — intenta leer uno de los registros configurados y muestra el valor.
3. Probar escritura — solicita un valor, lo escribe, y lo vuelve a leer para confirmar.

Estas pruebas se ejecutan síncronamente desde el worker y te dan feedback antes de publicar el cambio a producción.

Beneficios clave

• Tres protocolos industriales nativos adicionales (Modbus, S7, CIP) sin gateway.
• Half-duplex completo: lectura continua + escritura bajo demanda.
• Listeners reconectables con backoff, supervisados por un worker dedicado.
• Dispatchers validados por tests (ver cobertura en tests/tools/test_tool_dispatch_service.py).
• Status en tiempo real vía Ably.
• Rate limiting + audit trail + confirmación humana como defensa en profundidad para escrituras.