Edição 233 - Controle & Instrumentação

Revista Controle & Instrumentação – Edição nº 233 – 2017

¤ Cover Page

Integração de protocolos na construção da Indústria 4.0

É impressionante o tanto de mudanças que a tecnologia trouxe, nas últimas duas décadas, para o cotidiano de indivíduos de todo o mundo e empresas de todos os setores. E muito está por vir com a Indústria 4.0 – termo já consagrado no Brasil para o ambiente industrial, criado pelas novas e disruptivas tecnologias, que ganha espaço principalmente na manufatura, enquanto que, no setor de processos, outros termos são mais frequentes, como smart industry, transformação digital (DX) e IIoT (Internet Industrial das Coisas). De qualquer forma, o novo ambiente produtivo tem, como um dos seus pilares, a interoperabilidade – capacidade de comunicação entre vários dispositivos por meio de mensagens trocadas entre eles através dos mais diversos padrões de tecnologias. É um ambiente em que os softwares ganham cada vez mais importância e os protocolos de comunicação desempenham papel-chave.

	“Vejo grandes mudanças no mercado de protocolos nos próximos anos – os baseados em Ethernet terão a predominância de comunicação, e aqueles com baixa velocidade e confiabilidade vão desaparecer”, vislumbra Cesar Roberto de Souza, professor do Senai Prof. Dr. Euryclides de Jesus Zerbini e membro da atual diretoria da ISA-Seção Campinas. Por isso, segundo ele, no Brasil, o grande desafio da Indústria 4.0 é nossa infraestrutura de telecomunicação. “O tráfego de dados é importante, pois estamos falando de milhões de dispositivos interconectados trocando dados com a rede”, destaca.

Cesar Cassiolato, da Vivace Instruments, alerta: “A indústria brasileira pouco se utiliza dos benefícios das tecnologias digitais e nossa inclusão neste cenário é essencial para o desenvolvimento e competitividade do país. Estamos atrasados.”

Marcos Pelizzer, da Rockwell Automation, endossa essa opinião: “no Brasil, a primeira barreira à Indústria 4.0 é o fato de o país ter um dos parques industriais tecnologicamente mais atrasados do mundo, com equipamentos automatizados que têm, em média, de 15 a 20 anos de funcionamento”.

É fato que há necessidade de investir pesado para modernizar a estrutura de telecom e o parque industrial nacional; mas, essa obsolescência que predomina internamente também é fruto da cultura das empresas, na avaliação de Thiago Gomides e Vinicius Ferraz, da Endress + Hauser. Para eles, “o grande desafio da Indústria 4.0 é cultural. Mudar o mindset é o primeiro passo para que possamos pensar em um conceito de digitalização. A companhia precisa ter uma cultura de inovação”.

Ricado Azevedo, gerente de produto da Phoenix Contact, lembra que “um ponto chave para a evolução nacional no sentido da Indústria 4.0 é a educação e a responsabilidade institucional e social das empresas na parceria com as instituições de ensino e capacitação”.

A necessidade de adotar esse novo paradigma é global, e traz outro grande desafio: o desenvolvimento de novas especialidades e a formação de profissionais capacitados. E, enquanto indústrias e governos mundo afora buscam formas de atender a essas demandas estruturais, a vida na fábrica segue lidando com as questões mais imediatas de produtividade, segurança e disponibilidade, com as máquinas, equipamentos e softwares em operação, geralmente de múltiplos fornecedores e com tecnologias em diferentes níveis. É nesse dia-a-dia que os protocolos já estão presentes, há décadas, e agora cumprem o papel de integrar a estrutura para a construção gradativa da Indústria 4.0.

Os especialistas elencam Profibus, Profinet, Mosbus, OPC e Ethernet/IP como os protocolos mais utilizados em ambiente industrial atualmente. Bruno Balbi da Costa, supervisor de eletrônica e analista de sistemas industriais Etesco, divisão Oléo & Gás, destaca que “o 4-20mA e o HART não vão deixar de existir. O sinal 4-20mA ainda é largamente utilizado e o HART, além de ser digital, traz vantagem para as organizações de pequeno porte, onde os investimentos com novas tecnologias são reduzidos”.

Sabino Ferrero, da Emerson, reforça essa opinião: “os instrumentos com protocolo HART e diagnósticos avançados podem gerar um conjunto maior de dados e de informações. Indústria 4.0 é uma evolução na planta existente, e não significa que todos os instrumentos já em operação tenham de ser substituídos”, opina.

“Acredito que o Profibus, Modbus, OPC e Ethernet/IP sejam os principais padrões industriais utilizados no momento, por serem nativamente baseados em redes Ethernet; mas, o 4-20mA e o Hart devem ser mantidos em conjunto com o gerenciamento de ativos,” afirma o executivo da Phoenix Contact.

Diante da diversidade de protocolos, é natural se questionar a possibilidade de desenvolvimento de um protocolo universal, mas é unânime que se trata de algo altamente improvável, mesmo no longo prazo. “Sempre existe algum nível de incompatibilidade entre os diversos fornecedores”, opina Pelizzer.

Na opinião de Jonas Berge, diretor de aplicações da Emerson em Singapura, a multiplicidade de protocolos é necessária para atender às múltiplas demandas. Para ele, “OPC é o sonho de uma única API (Application Programming Interface) para software de automação”. Ele afirma que, “à medida que softwares de aplicação industrial ganham importância, o OPC se torna, também, mais e mais importante, por ser a interface-chave entre aplicações de software. OPC permite que os dados passem de uma aplicação de software para outra. Essas aplicações falam OPC e é assim que se obtêm os dados”, destaca ele.

“O OPC permite transportar os dados de processo, independente do protocolo industrial utilizado, e disponibilizá- los para um sistema de supervisão e controle virtual”, detalham os engenheiros da Endress + Hauser. Cassiolato vê no OPC a “solução completa para as necessidades de todas as camadas verticais de acesso em dispositivos remotos. Ele fornece a semântica de interoperabilidade para o mundo inteligente de sistemas conectados. A agregação de informação sobre muitas camadas é crítica e de fundamental importância e a adoção deste padrão aberto é a oportunidade que gera valor para fornecedores e usuários.”

O OPC é uma interface padrão para obter dados no software de automação, permite que o software obtenha dados de outros softwares, sistemas e sensores subjacentes e outros dispositivos. Por exemplo, um sensor sem fio está conectado a um gateway wireless com um servidor OPC, que permite que o software-cliente obtenha os dados do sensor. Assim, todos os gateways, PLCs e outros dispositivos já vêm com um servidor OPC, nos últimos 20 anos, para permitir a sua integração com qualquer tipo de software de automação. Os DCSs também suportam OPC, para que possam passar dados para sistemas de nível superior – clientes OPC como historiadores (PIMS), todos os tipos de softwares analíticos, sistemas de execução de fabricação (MES), controle de processo avançado (APC), otimização em tempo real (RTO), ajuste de loop, controle de processo estatístico, simulação de processo, simulação de treinamento de operador (OTS), Realidade Aumentada (AR), reconciliação de dados e contabilidade de produção, etc.

“O papel do OPC se torna mais importante à medida que mais e mais aplicações de software são introduzidas para ajudar a melhorar o desempenho da planta. Observe que o termo “analítica” é abrangente para todos os tipos de análise, como análise de processos, de lote, de monitoramento de condições de equipamentos, de desempenho de equipamentos e gerenciamento de energia (EMIS), etc. Outro motivo para o destaque do OPC é porque, com as análises, você deseja agregar dados de múltiplas fontes, como historiador, DCS, PLC, sistema de proteção de turbomáquinas, gateways wireless, etc. E o OPC permite que você faça isso sem precisar de um software intermediário” comenta Jonas Berge.

Bruno acha importante pontuar que “o OPC não é um protocolo de rede industrial, mas, sim, um framework operacional para manter comunicação de sistemas de controle de processo baseados em Windows, usando o protocolo Object Linking and Embedding (OLE). Diferentemente de outros protocolos de comunicação de redes industriais, sua principal função é interconectar sistemas de controle distribuídos com Windows Hosts tipicamente através de redes TCP/IP. O OPC funciona basicamente de forma cliente/servidor, onde um aplicativo cliente chama um processo local, mas, em vez de executar o processo usando o código local, o processo é executado em um servidor remoto.” Independentemente de como é chamado, Sabino resume: “o OPC se integra bem com os outros protocolos” e levanta uma questão da maior relevância: “É fundamental ter em mente que a segurança de informação e de dados é muito importante e que a utilização de versões antigas de OPC pode ser um ponto de vulnerabilidade”. De fato, versões antigas do OPC, que ainda se utilizam de mecanismos DCOM para a proteção da conexão, vão sempre gerar dificuldades na integração com outros protocolos.

Desafios: segurança, custos, atualizações

As informações geradas pelo controle de processo são utilizadas para nortear a organização no dia a dia, em seu plano estratégico e, numa planta conectada, a segurança da informação está no topo da lista de prioridades. “Atualmente, isso é feito através da integração entre TA (Tecnologia de Automação) e TI (Tecnologia da Informação). Portanto, sabemos que, sem a devida proteção, se pode ter um cenário catastrófico em caso de ataque cibernético do tipo MITM (Man-in-the-Middle), que pode interromper operações normais do protocolo, potencialmente alterar ou manipular mensagens de protocolo para roubar informações, cometer fraude ou causar uma falha no próprio processo de controle”, avalia Balbi.

“Segurança é crítica, pois qualquer tipo de sabotagem em operações automatizadas gera transtornos e prejuízos incalculáveis. A análise de riscos, estratégias de prevenção contra softwares invasores, armas cibernéticas, gestão de continuidade de negócios, no caso de incidentes no ambiente de redes industriais, assim como a implementação de um ambiente de monitoramento contínuo, em uma rede de automação, são obrigatórios para manter um sistema seguro, confiável e disponível”, pontua Cassiolato.

Para a Endress + Hauser, o custo de implementação de hardwares necessários para disponibilizar os dados é outro grande desafio enfrentado pelo OPC. De tempos em tempos, há uma atualização necessária da tecnologia e, com isso, atualizações de padrões de comunicação do hardware e do software de automação. Nem todos os fabricantes mantêm o mesmo padrão, ou até mesmo criam novas funcionalidades, o que torna necessário atualizar os drives de comunicação do OPC. Uma padronização mundial dos fabricantes na parte de comunicação seria um grande avanço na área de automação, porém exige um grande esforço e entendimento de todos os fabricantes para criar este padrão.

Sobre a versão UA (Unified Architecture) do OPC, o professor Cesar Roberto de Souza diz que ela “é definida como um padrão aberto independente de uma determinada plataforma, ou seja, podem ser utilizados Windows, MAC, Android, Linux.” Jonas Berge explica que OPC UA é o padrão OPC amigável a firewalls. “O OPC Classic, criado há mais de 20 anos, tinha três ou mais partes (OPC-DA, OPC-A e E e OPC-HDA, etc.) e ainda serve bem as indústrias, porém, com limitações, sobretudo de segurança, pois foi criado com base na tecnologia DCOM, da Microsoft, o que significa dizer que o OPC Classic funciona bem em um computador ou numa pequena rede LAN de uma sala de controle usando DCOM (Distributed COM). Mas, as plantas agora querem passar dados através do firewall, que fica entre a infraestrutura operacional (sistema de controle e historiador, etc.) e a infraestrutura de TI, de modo que os gerentes e engenheiros possam obter dados de processos e equipamentos onde estiverem. Algumas empresas querem estabelecer um centro de gerenciamento a partir do qual monitorem equipamentos em várias fábricas, ou um centro de operações integradas (iOps) para supervisionar a produção em locais remotos, como offshore. E isso o OPC Classic não pode fazer. Existem várias soluções proprietárias para “tunelar” OPC Classic, mas não é uma solução prática. O OPC-UA é um padrão amigável. Como o OPC Classic original funcionou bem dentro da sala de controle, muitos nem pensaram em atualizar para o OPC-UA, até tentarem transferir dados para além da sala de controle.” Jonas Berge lembra que muitos sistemas ainda não suportam OPC-UA. “Sem problemas, porque você pode usar um Proxy OPC, que é um tipo de gateway entre OPC Classic e OPC-UA”.

A crescente interação entre TI e TA vem desconstruindo a tradicional pirâmide da automação, na qual a relação cliente-servidor é vertical e de cima para baixo. Na Indústria 4.0, os dispositivos ou serviços podem se comunicar autonomamente com outros, independentemente do nível que ocupam na pirâmide de automação. O OPC UA viabiliza que dispositivos compartilhem seus dados diretamente ou em paralelo com CLPs, sistemas MES, nuvem, ERP. Segundo a OPC Foundation, “OPC UA, combinado com comunicação TSN, é capaz de ser real-time. A complexa configuração das redes TSN é um desafio a ser vencido”, afirma seu presidente no site da fundação.

E, como será que alguns players do mercado de automação imaginam o futuro dos protocolos de comunicação daqui a cinco, dez anos? A Endress + Hauser estima que, em 2025, 43% da economia mundial estarão baseados em IoT. “Na indústria, tendemos a utilizar ainda mais protocolos baseados em Ethernet para facilitar a troca de dados. Em dez anos, acredita-se que a IA (inteligência artificial) tenda a nos ajudar em relação a toda a cadeia produtiva, em todo o monitoramento do ciclo de vida do ativo, tornando efetivo o conceito de manutenção prescritiva, integrando-se com sistemas de ERP, logística, compras e fornecedor”, vislumbram Thiago Gomides e Vinicius Ferraz.

“Em cinco anos, muitas das tentativas atuais de implementação de redes para a Indústria 4.0 não vão estar trabalhando conforme planejamento original, seja pelo uso de tecnologias não maduras, ou pelo desenho de topologia excessivamente complexo. As que passarem por estas falhas de desenho, já em cinco anos, vão estar mostrando o valor de retorno do investimento. Em dez anos, acredito que o número de protocolos utilizados vai ser menor, com os clientes procurando por soluções consolidadas”, opina Sabino.

Cassiolato percebe duas realidades: “nos países mais desenvolvidos, acredito que o nível de evolução será enorme, o que facilitará mais ainda a eles um maior grau de competitividade. No Brasil, como o ritmo é outro, para se pensar cinco ou dez anos à frente, precisamos começar hoje”. Pelizzer acredita que, “em cinco anos, a tecnologia de OPC-UA será a mais utilizada e, em 10 anos, novas tecnologias surgirão com impacto ainda maior na automação.”

“Os protocolos estão convergindo para tecnologias baseadas em redes ethernet e computação em nuvem. Pode-se dizer que o Brasil está na fase da indústria 2.5, com a força de trabalho voltada para este cenário, e o futuro é a digitalização, onde os processos deverão ser mais descentralizados, com uma maior integração de TI e nuvem. Muitos já estão buscando atualização,” pontua Ricardo.

O professor Cesar repete o alerta: “As empresas que não investirem nessas tecnologias estão fadadas a ficar em segundo plano, pois seus custos serão maiores que as empresas que investirem agora”. Ele arremata com a questão estrutural das competências, ao prever que “os empregos com baixa qualificação sofrerão uma diminuição drástica, porém, os com alta qualificação irão aumentar”.

Diz mestre Marcos Peluso, distinguished technologist da Emerson: “ainda que eu concorde que esta é a arquitetura que melhor pode servir à indústria e que, sem dúvidas, será o que veremos no futuro, tenho de lembrar que é a mesma ideia básica que propusemos há 20 anos. Inteligência em todos os níveis, total comunicação e comunicação entre pares, uso de soluções abertas, etc.

É claro que a tecnologia evoluiu e a capacidade de transferir dados de maneira mais rápida e eficiente aumentou exponencialmente nesses 20 anos. E a disponibilidade de equipamentos e ferramentas inteligentes abriu as portas para o aumento de produtividade. Mas a indústria de processos, não só a brasileira, é de uma inércia enorme. O pessoal tem medo de novas tecnologias. A maioria das pessoas se sente mais à vontade com velhos problemas do que com novas soluções. Para piorar as coisas, a segurança cibernética tem feito todo mundo tremer e está colocando um bocado de pedras nos caminhos das empresas e dos cidadãos. O engenheiro que tem sua conta bancária pessoal hackeada vai pensar dez vezes antes de colocar a segurança de sua empresa em perigo.

Já estive em muitas indústrias nos Estados Unidos que praticamente não utilizam comunicação digital em suas plantas. Em algumas, nem mesmo 4-20 mA! O Hart está disponível há séculos, praticamente todos os instrumentos de campo e sistemas o suportam, e são poucos os que tiram vantagem da tecnologia. A aceitação da comunicação digital tem sido muito lenta, com raras e honrosas exceções. Ironicamente, ela é mais popular em países não tão desenvolvidos. Visitei refinarias mais modernas no Brasil e na Índia do que nos Estados Unidos. É claro que a base instalada americana é muito antiga e ninguém troca toda a instrumentação de campo sem uma justificativa muito forte.

No chão de fábrica, o pessoal está preocupado em fazer a fábrica rodar; no nível corporativo, existe a vontade de aplicar soluções de IIoT e Indústria 4.0 – isso já vem ocorrendo pontualmente. Para os puristas: eu sei que existem mais níveis e que temos que buscar uma horizontalização, só estou tentado simplificar. Mas isso mostra a necessidade de buscar uma boa, eficiente e segura interface entre estes dois níveis. Por um bom tempo, a base instalada só vai poder prover dados através dos protocolos de comunicação existentes. Mesmo que tivéssemos hoje um protocolo aberto baseado em Ethernet e que fosse intrinsecamente seguro para áreas classificadas, teríamos de esperar vários anos para que uma migração significativa para a nova tecnologia ocorra no campo. Enquanto isso, OPC UA pode transferir os dados de protocolos tradicionais para edge computers, diodos de dados, nuvem, etc. com toda segurança necessária. OPC UA traz grandes vantagens e está fazendo da integração algo mais fácil. O velho OPC já causou muita dor de cabeça, a ponto de ter sido chamado “Oh Please, Communicate”.

Breve história

Atualmente, OPC significa Open Platform Communications. Mas, em seus primórdios, nos anos 90, OPC era o acrônimo para OLE for Process Control, em que OLE significa Object Linking and Embedding. Nessa época, formou-se uma força-tarefa composta por empresas interessadas em criar um padrão para acesso a dados em COM e DCOM, da Microsoft. Esse grupo se autonomeou OPC e logo ficou clara a necessidade de formalização, o que ocorreu no ISA Show de 1998, em Chicago, com a OPC Foundation. Contínuos desenvolvimentos culminaram no que temos hoje: uma plataforma que extrapolou o nicho de indústrias de processo, uma camada de software responsável por traduzir as informações de diversos protocolos através de drives desenvolvidos para cada fabricante de automação.

Como integrar protocolos com OPC?

Jonas Berge aponta quatro regras básicas:

# 1: use OPC e não mais APIs personalizadas entre aplicativos; se o software de automação não suportar OPC, não compre.

# 2: use o protocolo “nativo” o mais possível e converta com OPC apenas no último momento antes de os dados entrarem no software. Ou seja, se os transmissores usam Foundation Fieldbus H1, use FF-HSE através da rede Ethernet antes de converter para OPC no servidor. Se os acionamentos do motor usam o Profibus-DP, use o Profinet através do cabo Ethernet e converta para OPC no servidor. A razão para isso é que, sempre que você converte o protocolo, alguns dados e significados (metadados) se perdem. Parte da razão pela qual o OPC tem tido tanto sucesso é que inclui um modelo de informação que aceita metadados. O modelo de informação torna muito fácil o software- cliente encontrar a informação certa no servidor OPC. Metadados permitem que o aplicativo- cliente OPC use os dados da maneira correta sem configuração adicional. E ainda, manter o protocolo nativo até o último momento ainda é melhor porque o OPC faz um excelente trabalho com variáveis de processo (PV), e os protocolos fazem um trabalho melhor com a configuração do dispositivo, os dados de diagnóstico, etc. preservando o DD.

# 3: use um servidor OPC feito pelo fabricante do hardware, não um servidor OPC genérico para o protocolo. Ou seja, se você tiver um PLC, compre o servidor OPC do fabricante do PLC. Mesmo se o PLC suportar a comunicação Modbus e você comprar um servidor genérico Modbus OPC, esse servidor nunca será tão bom quanto o servidor OPC criado especificamente para o PLC. É por isso que Modbus é baseado em dados alocados em registros numerados. Se você usar um servidor genérico Modbus OPC, você deve configurar manualmente os números de registro nesse servidor OPC que corresponda aos números de registro no PLC. Você também deve cuidar dos tipos de dados e do mapeamento de bits, etc. Se a configuração do PLC for alterada, o servidor OPC também deve ser alterado. Isso é muito trabalhoso e propenso a erros. Se você comprar um servidor OPC com o PLC, o software de configuração do PLC também configurará automaticamente o servidor OPC, economizando toneladas de trabalho.

# 4: evite o software “intermediário” da plataforma para agregação de dados. Use o software-cliente OPC e deixe esse software obter os dados diretamente de um ou mais servidores OPC; da mesma forma com o historiador, DCS, PLC ou gateway wireless, etc. O motivo é que as plataformas de middleware e os corretores convertem os dados do OPC em formatos proprietários que causam a perda da capacidade de navegar no modelo de informação do OPC e nos metadados, e aí os dados devem ser mapeados novamente para os clientes do OPC, o que custa para comprar e manter. Lembre-se que o OPC já é uma “plataforma virtual” para hardware e software trocarem dados.