6 perguntas para avaliar qual comunicação usar na convergência da automação industrial e TI?
Redes de comunicação industrial como Profinet, Ethernet/IP, IEC-61850, etc. cumprem seu papel ao garantir comunicação confiável entre dispositivos e controladores na automação industrial. Por outro lado, com a crescente conexão da automação com aplicações na rede de TI ou com serviços na nuvem, avaliar as opções de comunicação para convergência de TO e TI se torna necessário. Mas qual padrão utilizar?
Numa visão simplificada, sem detalhar cada padrão de comunicação seguem algumas perguntas para avaliar as opções:
1. Qual o problema ou desafio a ser resolvido com a comunicação desejada?
Essa pergunta inicial é obvia, mas é necessária logo no inicio já que podemos decidir por opções para atender uma necessidade especifica de comunicação com a escolha mais simples e direta, ou uma opção estratégica para outras integrações que podem estar planejadas. Por exemplo, para uma necessidade de comunicação com de um PLC com um PIMS você pode escolher um driver proprietário, mas pensando em médio prazo, pode avaliar a conexão via OPC UA pensando em padronizar a segurança, a estrutura de dados na integração com outros sistemas.
2. Qual o fluxo de dados necessário?
Verificar qual aplicação necessita receber os dados e qual irá os fornecer, assim como qual quantidade de dados (tags, pontos, variáveis, etc.) por segundo (throughput) serão transmitidas são detalhes obrigatórios a verificar. Será somente leitura ou escrita, ou ambos? Não importa a comunicação que escolha, há um limite para obter um ótimo desempenho. Por outro lado, escolher uma alternativa que trafega “milhões” de dados enquanto necessita apenas comunicar 100 tags a cada 5 segundos pode não ser a solução com melhor relação custo/benefício.
3. Quais os requisitos de segurança de conexão, acesso aos dados e confiabilidade?
Talvez muitos já teriam pulado de cara para próximo tópico na avaliação das opções de comunicação, mas verificar os requisitos de segurança e confiabilidade antes pode ser um fator crucial não somente sobre a decisão de qual padrão de comunicação utilizar, mas também na escolha da melhor arquitetura, infraestrutura de rede, permissões em firewalls, redundancia, buffer, etc. assim como no planejamento de treinamentos e manutenção.
4. Quais os padrões de comunicação disponíveis do lado de TI ou da nuvem?
Aplicações como MES e PIMS, em geral disponibilizam clientes OPC DA ou OPC UA em seus coletores, mas também tem opções de comunicação via drivers proprietários que podem se conectar diretamente a PLCs por exemplo. Bancos de dados em geral tem comunicação aberta ODBC e JDBC, mas opções como ADO e OLE DB podem também estar disponíveis. Dependedo do fabricante ou módulo de um ERP e WMS, a comunicação aberta via OPC DA ou UA pode estar disponível, mas o comum é via APIs ou webservices, além de add-ins, como para planilhas por exemplo. Azure e AWS tem em suas opções de arquitetura comunicação via OPC UA, MQTT e APIs, enquanto o Google Cloud apenas via sua API REST/gRPC chamada PubSub. Aplicações móveis em geral tem interface via API REST. Fornecedores de serviços IIoT que disponibilizam seus próprios sensores e gateways, utilizam 3G/4G, LORA e NB-IoT em comunicação proprietária, enquanto aqueles que proveem apenas o software como serviço, tem comunicação principalmente via OPC UA e MQTT.
5. Quais os padrões de comunicação disponíveis nos dispositivos ou sistemas industriais?
A lista de possíveis padrões de comunicação disponíveis na automação industrial é enorme, mas com foco na convergencia de TO e TI podemos definir as opções mais comuns. Em novos PLCs tem se tornado comum a disponibilidade de OPC UA nativo, enquanto MQTT esta presente em poucas opções, principalmente controladores de pequeno porte, embarcados e sensores que tem foco em atender a conexão direta com brokers para aplicações de IIoT. Para comunicação com a maioria dos PLCS do parque instalado nas indústrias, drivers proprietários são utilizados em aplicações IHM/SCADA ou servidores OPC DA classic instalados em estações Windows para disponibilizar dados de maneira aberta. Gateways fisicos de protocolos também tem se tornado comuns para conversão de protocolos industriais em OPC UA ou MQTT, visando atender necessidades especificas. Sistemas SCADA em geral tem disponibilidade de clientes e servidores OPC DA e esta se tornando comum também OPC UA.Algumas opções disponibilizam acesso a dados históricos e de alarmes e eventos via OLE DB ou ODBC, além de OPC HDA e A&E.
6. Qual padrão de comunicação adotar?
Embora não exista uma resposta única para atender todas as necessidades, o OPC UA é a principal opção para a maioria dos cenários de integração entre a automação industrial, TI e serviços em nuvem. Já presente em dispositivos, sistemas industriais e aplicações de TI, o OPC UA permite uma conexão direta e segura. Para facilitar a conexão com multiplos servidores OPC UA e estruturar os dados para clientes OPC UA, aplicações como o Matrikon Data Broker podem ser adotadas. OPC DA classic é uma alternativa de integração limitada a cenários em que não há firewalls habilitados ou que ambos lados da comunicação utilizam este padrão. Uma “atualização” do OPC DA classic para comunicação via OPC UA pode ser realiza com o uso do Matrikon Tunneller por exemplo. Como não esta disponível na maioria dos dispositivos e sistemas de automação industrial, o MQTT tem suas vantagens principalmente na integração com serviços IIoT, aplicações e dispositivos na camada “edge” que já incluem brokers MQTT. Aqui é importante considerar opções que tem OPC UA PubSub, padrão que também pode fornecer MQTT como meio de transporte de dados. E quanto ao uso de APIs? Em geral elas estão disponíveis nos sistemas de TI e aplicações em nuvem, e são a principal opção para coletar dados desses sistemas. Um exemplo são fornecedores de serviços IIoT que coletam os dados através de sua estrutura dedicada, armazenam os dados em nuvem e disponibilizam para clientes os dados via API REST.
