Me dedico al desarrollo, implementación y operación de sistemas automáticos de control de procesos (ACS TP). Inicialmente, trabajó con sistemas SCADA. Luego pasó rápidamente a trabajar con protocolos para el intercambio de dispositivos industriales. Tanto los controladores de auto escritura como la configuración de sistemas de recolección de datos. En este momento, mi trabajo está pasando por la atmósfera de Modbus-s, IEC-101/104-s, OPC y otros protocolos.
Fig. 1. La variedad de protocolos de comunicación utilizados en los sistemas de control industrial.Brevemente sobre cómo funciona un sistema típico de recolección de datos (un poco simplificado).
Fig. 2. Sistema de adquisición de datosUn software especial llamado servidor OPC sondea los dispositivos conectados a la interfaz RS-485. El servidor OPC es una especie de capa entre el sistema SCADA y los dispositivos, que traduce el idioma en el que los dispositivos se comunican a un idioma que es comprensible para el sistema SCADA. El convertidor Ethernet / RS-485 se utiliza para convertir paquetes TCP / IP en paquetes que viajan a través del entorno físico de RS-485.
Este esquema tiene varias desventajas:
- Establezca, por ejemplo, en el servidor OPC un tiempo de espera de espera de una respuesta de 200 ms. En el caso ideal, cuando los paquetes van a Ethernet sin demoras, la comunicación con los dispositivos se realiza a una buena velocidad (intensidad). Pero si el paquete que contiene la respuesta se retrasa, por ejemplo, 300 ms (esto es más que el tiempo de espera de respuesta de 200 ms), entonces el servidor OPC considera que la respuesta a la solicitud no ha llegado y envía la siguiente solicitud. En este momento, llega la respuesta a la solicitud anterior, pero el servidor OPC piensa que esta es la respuesta a la solicitud actual y envía los datos incorrectos al principio. Como resultado, los datos en la estación de trabajo "saltan". Para alejarnos de tales situaciones, estableceremos un tiempo de espera más. Tomar con un margen de 3000 ms. Si la respuesta llega antes de 3000 ms, entonces no esperamos el tiempo restante, procedemos a la siguiente solicitud. Hasta ahora, todo va bien, pero tan pronto como varios dispositivos dejan de responder, hay retrasos de 3000 ms para cada dispositivo. El tiempo de votación está aumentando.
- La mayoría de los protocolos utilizados en los sistemas de control de procesos (Modbus, medidores de electricidad) se basan en encuestas secuenciales de los mismos parámetros. Dado que la mayoría de las veces los valores de los parámetros permanecen sin cambios, la red de datos se utiliza para transmitir los mismos. Esto es irracional si el medio de transmisión es GPRS y el tráfico cuesta dinero. Además, en un medio de transmisión GPRS, los retrasos de paquetes pueden alcanzar varios segundos. ¿Por qué perder tiempo y recursos transfiriendo lo mismo?
Para las situaciones anteriores, un protocolo es más adecuado en el que los datos se transmiten hacia arriba por cambio (esporádicamente) y se agrupan por varios valores en un paquete TCP. Dichos protocolos son IEC-60870-5-104 y OPC UA. ModBus-TCP también es adecuado, no hay transferencia de cambio en él, pero luego, si no hay muchos datos, se pueden empaquetar en un solo paquete. Sería bueno tener algún tipo de controlador que se pueda colgar en un riel DIN, conectar dispositivos a través de RS-485 y transferir datos a través de Ethernet al sistema SCADA.
En general, hay algunas puertas de enlace de hardware en cantidades considerables. Pero en forma de soluciones indivisibles ya hechas. Todo en uno. Y realmente no me gusta. Una vez necesitaba una puerta de enlace que convirtiera los protocolos de los medidores SET-4TM en OPC UA con seis puertos RS-485 y dos Ethernet. Un fabricante tiene una puerta de enlace que admite los protocolos de intercambio necesarios, pero pocos puertos RS-485, el otro tiene el número correcto de puertos RS-485, pero no hay dos puertos Ethernet. El tercero tiene dos puertos Ethernet, pero no todos los protocolos de comunicación. El cuarto tiene casi todo, pero no hay OPC UA, disponible a bordo del IEC-60870-5-104 o ModBus-TCP requiere un servidor OPC para estos protocolos.
Y qué maravilloso sería: comprar un controlador o una mini PC con sistema operativo de un fabricante. Compre software para el controlador de otro. Si un fabricante de software no admite algo, compre uno del software de otro, combine los componentes de software a través de una interfaz de software estándar. ¡Parece que aquí hay un futuro brillante!
Es por eso que las puertas de enlace de protocolo se usan con menos frecuencia que el servidor OPC y el paquete de convertidor de Ethernet a RS-485 debido a su indivisibilidad en los componentes.
Una de las razones por las cuales SCADA para Linux está subdesarrollada: SCADA está allí, hay pocos protocolos de intercambio compatibles y no hay servidores OPC para la comunicación con el equipo. SCADA deja el integrador uno a uno con el hardware.
El lector ya puede hacer una pregunta: ¿Qué puede ofrecer? ¿Qué hay ya allí? Hay servidores OPC UA para Linux para los siguientes protocolos:
Para transmitir datos al nivel superior no solo a través del protocolo OPC UA, se han creado el "
Convertidor OPC UA a Modbus e IEC 60870-5-104 ". Además de la función de transferencia de datos de estos protocolos, el "Convertidor" tiene un servidor web incorporado. Con un editor especial, puede dibujar un diagrama, mostrar los valores de las etiquetas y luego abrirlo en un navegador. Resulta mini-SCADA directamente en el controlador. Cómo funciona la animación del circuito, ya escribí
aquí , sobre el editor
aquí . En el futuro, se planea el "Convertidor OPC UA a MQTT".
Los servidores y convertidores OPC UA funcionan en arquitecturas x64, ARMv7 y AARCH64.
Por lo tanto, para el hardware, puede utilizar soluciones probadas en el tiempo basadas en mini computadoras industriales y todo tipo de minicomputadoras ARM "compatibles con raspberry pi". Cómo instalar y configurar el software con ejemplos se puede leer
aquí o
aquí .
En general, la estructura del complejo se ve así:
El sistema es escalable. Se utilizan los componentes necesarios solo para resolver el problema actual.
Usando el servidor OPC UA, nuestro esquema se transforma:
Tenemos lo siguiente:
- El servidor OPC UA recopila datos de dispositivos a través de RS-485 sin grandes demoras entre las solicitudes;
- Los datos en SCADA se emiten en varias partes en un paquete TCP para cambio;
- Puede conectar varias estaciones de trabajo igualmente configuradas al servidor OPC UA. Útil si se necesita duplicación.
Por lo tanto, en lugar de un paquete de servidor OPC y "Convertidor de Ethernet a RS-485", obtenemos un dispositivo que combina su funcionalidad. Me gusta más este esquema. Que hay de ti