Arquitectura maestro / estación remota

Quién inicia y quién responde

El rasgo definitorio de la arquitectura es la asimetría de la iniciativa. El maestro es la parte activa: decide cuándo comunicar, a qué dispositivo direccionar y si solicitar datos o enviar un comando. Una estación remota es la parte reactiva: escucha una solicitud dirigida a ella, y solo entonces responde con los valores pedidos o reconoce un comando ejecutado. En el modelo clásico, una estación remota nunca ofrece información por su cuenta: espera a ser sondeada, y su rol es responder con exactitud y prontitud cuando lo es.

Esta disciplina de solicitud y respuesta es lo que hace viable un enlace compartido. Como solo el maestro inicia, hay una sola autoridad que decide quién habla y cuándo, así que muchas estaciones remotas pueden compartir una línea serial o un canal de radio sin colisionar: el maestro las direcciona una a la vez y ellas se turnan para responder. Quite ese único punto de iniciativa y tendría dispositivos intentando transmitir cuando les plazca, pisándose entre sí. La estructura maestro / estación remota es, en el fondo, una manera de arbitrar limpiamente un medio compartido.

Los roles tratan de comunicación, no de inteligencia o capacidad. Una estación remota puede ser una RTU sofisticada corriendo sus propios lazos de control local, mucho más lista que el motor de sondeo que la consulta, y aun así en la relación de comunicación sigue siendo la estación remota porque responde en lugar de iniciar. Por eso los roles se entienden mejor como una topología de quién le pregunta a quién, superpuesta a lo que sean los dispositivos como hardware. La misma RTU física es una estación remota para su maestro y podría ser un maestro para dispositivos debajo de ella.

Sondeo, eventos y desviaciones del maestro / esclavo puro

Los roles de maestro / estación remota son sobre lo que se construye toda la maquinaria de sondeo. La tasa de sondeo, la programación del sondeo, la rotación round-robin, los reintentos y los tiempos de espera describen todos cómo el maestro conduce su lado de la relación de solicitud y respuesta: con qué frecuencia pregunta, en qué orden y cómo decide que una estación remota no respondió. Ninguno de esos conceptos tiene sentido sin la arquitectura subyacente: son todos elaboraciones de un maestro que atiende a sus estaciones remotas una solicitud a la vez. Entender primero los roles es lo que vuelve legible el resto de la comunicación SCADA.

Algunos protocolos relajan la regla pura de que una estación remota nunca habla sin que se le pida. El reporte por excepción y el reporte no solicitado dejan que una estación remota inicie un mensaje para avisar al maestro de un cambio significativo sin esperar el próximo sondeo. Incluso aquí, sin embargo, los roles permanecen: la estación remota reporta al maestro, y el maestro sigue siendo la autoridad central a la que la estación reporta hacia arriba. El reporte no solicitado es un refinamiento de la relación por eficiencia, no una reversión de ella, y el maestro normalmente aún sondea por integridad de forma periódica para mantener correcta la imagen.

La arquitectura también escala en niveles. Un maestro en el centro de control sondea estaciones remotas en el campo, pero uno de esos dispositivos de campo puede él mismo ser un maestro para una subred de dispositivos debajo, agregando sus datos y presentándolos hacia arriba como una sola estación remota. Ese apilamiento es cómo se construyen los grandes sistemas de telemetría - una jerarquía de relaciones maestro / estación remota en vez de una plana - y es posible precisamente porque los roles son relativos a un enlace, no propiedades absolutas de un equipo. El rol de un dispositivo depende de cuál conversación se esté mirando.

La arquitectura en el SCADA en la nube y las operaciones remotas

En el SCADA en la nube para petróleo y gas, el rol de maestro se mueve de una computadora dedicada del centro de control a la plataforma misma, pero la topología no cambia: la plataforma es el maestro que alcanza a las estaciones remotas de campo - RTU, PLC, computadoras de flujo - a través de enlaces celulares, de radio o satelitales, y esos dispositivos responden. La ubicación física del maestro se corre a la nube, y aun así sigue iniciando cada conversación y sigue arbitrando el acceso a cada enlace de campo compartido igual que siempre lo hizo una estación maestra tradicional.

Una plataforma como Merobix actúa como ese maestro, sondeando estaciones remotas, emitiendo comandos de control y, donde los protocolos lo soportan, aceptando reportes no solicitados de cambios significativos entre sondeos. Enmarcar el despliegue en estos términos de rol es lo que vuelve predecible el comportamiento: un ingeniero sabe que la plataforma conduce el horario, decide el orden de sondeo y detecta una estación remota que no responde mediante tiempos de espera y reintentos, exactamente como la arquitectura prescribe. La nube no cambia los roles; cambia dónde vive el maestro.

Para las operaciones remotas, el valor práctico de entender la arquitectura es que explica tanto las fortalezas como los límites del sistema. Como el maestro inicia, los datos son tan frescos como el último sondeo, y una estación remota en un enlace compartido compite con sus vecinas por la atención del maestro, que es por qué importan la programación del sondeo y el reporte de eventos. Ver todo el campo como un maestro que atiende a muchas estaciones remotas es el modelo mental que vuelve coherente cada decisión de ajuste aguas abajo, de la tasa de sondeo a los conteos de reintentos, en lugar de una bolsa de ajustes sin relación.

Preguntas frecuentes