Estou envolvido no desenvolvimento, implementação e operação de sistemas de controle automático de processo (ACS TP). Inicialmente, ele trabalhou com sistemas SCADA. Em seguida, ele rapidamente passou a trabalhar com protocolos para troca de dispositivos industriais. Drivers de gravação automática e configuração de sistemas de coleta de dados. No momento, meu trabalho está passando pela atmosfera de Modbus-s, IEC-101/104-s, OPC e outros protocolos.
Fig. 1. A variedade de protocolos de comunicação utilizados em sistemas de controle industrialBrevemente sobre como um sistema típico de coleta de dados funciona (um pouco simplificado).
Fig. 2. Sistema de Aquisição de DadosUm software especial chamado servidor OPC pesquisa dispositivos conectados à interface RS-485. O servidor OPC é um tipo de camada entre o sistema e os dispositivos SCADA, traduzindo o idioma no qual os dispositivos se comunicam em um idioma compreensível para o sistema SCADA. O conversor Ethernet / RS-485 é usado para converter pacotes TCP / IP em pacotes que trafegam pelo ambiente físico do RS-485.
Este esquema tem várias desvantagens:
- Defina, por exemplo, no servidor OPC um tempo limite de espera por uma resposta de 200 ms. No caso ideal, quando os pacotes vão para a Ethernet sem atrasos, a comunicação com os dispositivos ocorre a uma boa velocidade (intensidade). Mas se o pacote que contém a resposta estiver atrasado, por exemplo, em 300 ms (este é mais do que o tempo limite da resposta de 200 ms), o servidor OPC considerará que a resposta à solicitação não chegou e envia a próxima solicitação. Nesse momento, a resposta para a solicitação anterior chega, mas o servidor OPC acha que essa é a resposta para a solicitação atual e envia os dados incorretos para o topo. Como resultado, os dados na estação de trabalho "saltam". Para evitar essas situações, definiremos um tempo limite mais. Tome com uma margem de 3000 ms. Se a resposta chegar antes de 3000 ms, não esperaremos o tempo restante, prosseguiremos para a próxima solicitação. Até agora, tudo está indo bem, mas assim que vários dispositivos param de responder, há atrasos de 3000 ms para cada dispositivo. O tempo de votação está aumentando.
- A maioria dos protocolos utilizados nos sistemas de controle de processos (Modbus, medidores de eletricidade) é baseada em pesquisa sequencial dos mesmos parâmetros. Como na maioria das vezes os valores dos parâmetros permanecem inalterados, a rede de dados é usada para transmitir os mesmos. Isso é irracional se o meio de transmissão for GPRS e o tráfego custar dinheiro. Além disso, em um meio de transmissão GPRS, os atrasos nos pacotes podem atingir vários segundos. Por que perder tempo e recursos transferindo a mesma coisa?
Para as situações acima, um protocolo é mais adequado no qual os dados são transmitidos para cima por alterações (esporadicamente) e agrupados por vários valores em um pacote TCP. Tais protocolos são IEC-60870-5-104 e OPC UA. O ModBus-TCP também é adequado, não há transferência de alterações, mas, se não houver muitos dados, eles podem ser empacotados em um pacote. Seria bom ter algum tipo de controlador que possa ser pendurado em um trilho DIN, conectar dispositivos a ele via RS-485 e transferir dados via Ethernet para o sistema SCADA.
Em geral, existem alguns gateways de hardware em números consideráveis. Mas na forma de soluções indivisíveis prontas. Tudo em um. E eu realmente não gosto disso. Certa vez, eu precisava de um gateway para converter os protocolos dos medidores SET-4TM em OPC UA com seis portas RS-485 e duas Ethernet. Um fabricante possui um gateway que suporta os protocolos de troca necessários, mas poucas portas RS-485, o outro possui o número certo de portas RS-485, mas não há duas portas Ethernet. O terceiro possui duas portas Ethernet, mas nem todos os protocolos de comunicação. O quarto tem quase tudo, mas não há OPC UA, disponível a bordo do IEC-60870-5-104 ou ModBus-TCP requer um servidor OPC para esses protocolos.
E como seria maravilhoso: comprar um controlador ou um mini-PC com sistema operacional de um fabricante. Compre software para o controlador de outro. Se um fabricante de software não suportar algo, compre um software de outro, combine componentes de software por meio de uma interface de software padrão. Parece que aqui é um futuro brilhante!
É por isso que os gateways de protocolo são usados com menos frequência do que o servidor OPC e o pacote de conversores Ethernet para RS-485 devido à sua indivisibilidade em componentes.
Uma das razões pelas quais o SCADA para Linux é subdesenvolvido: o SCADA está disponível, poucos protocolos de troca são suportados e não há servidores OPC para comunicação com o equipamento. O SCADA deixa o integrador um a um com o hardware.
O leitor já pode fazer uma pergunta: O que você pode oferecer? O que já está lá? Existem servidores OPC UA para Linux para os seguintes protocolos:
Para transmitir dados para o nível superior, não apenas através do protocolo OPC UA, foram criados o “
Conversor OPC UA para Modbus e IEC 60870-5-104 ”. Além da função de transferência de dados desses protocolos, o “Conversor” possui um servidor web embutido. Usando um editor especial, você pode desenhar um diagrama, exibir os valores de tag e abrir em um navegador. Acontece mini-SCADA diretamente no controlador. Como a animação do circuito funciona, eu já escrevi
aqui , sobre o editor
aqui . No futuro, está planejado o “OPC UA to MQTT Converter”.
Os servidores e conversores OPC UA funcionam nas arquiteturas x64, ARMv7 e AARCH64.
Portanto, para o hardware, você pode usar soluções testadas pelo tempo com base em mini computadores industriais e todos os tipos de minicomputadores ARM "compatíveis com raspberry pi". Como instalar e configurar o software com exemplos pode ser lido
aqui ou
aqui .
Em geral, a estrutura do complexo é assim:
O sistema é escalável. Os componentes necessários apenas para resolver o problema atual são usados.
Usando o servidor OPC UA, nosso esquema é transformado:
Temos o seguinte:
- O servidor OPC UA coleta dados de dispositivos via RS-485 sem grandes atrasos entre solicitações;
- Os dados no SCADA são emitidos em várias partes em um pacote TCP para alteração;
- Você pode conectar várias estações de trabalho igualmente configuradas ao servidor OPC UA. Útil se a duplicação for necessária.
Assim, em vez de um pacote de servidor OPC e “Ethernet to RS-485 Converter”, obtemos um dispositivo que combina sua funcionalidade. Eu gosto mais desse esquema. E você?