Software de Controle Inteligente e HMI: Capacitando Engenheiros a Construir Redes IIoT de Próxima Geração

Marissa Tucker da Parker Hannifin conversa com Editor Sênior Patrick Waurzyniak

[Imagem: Marissa Tucker]

Marissa, qual o papel do controlador de movimento no Industrial Internet of Things [IIoT], e que software está envolvido?

Iríamos além do controlador de movimento: o controlador de automação programável [PAC] desempenha maior papel no IIoT. Porque, além de ter lógica da máquina, PACs incluem controle de movimento como parte de suas rotinas e frequentemente têm interface homem-máquina [HMI] embutida. Beleza desta abordagem: programa não precisa compartilhar tags entre dispositivos porque componentes estão no mesmo dispositivo usando mesma lógica. Não só reduz tempo programação, facilita capacidades IIoT.

Exemplo: Erro de posição — antes específico ao controlador movimento — é automaticamente acessível pelo HMI embutido. Se HMI embutido tem capacidades web-server (muitos têm), HMI envia alerta imediato ao operador local e também ao gerente da planta via e-mail ou SMS. Muito melhor que abordagem tradicional: controlador movimento envia erro ao PLC, PLC processa dados só para enviar ao HMI — que pode não ter web server. Transferência complexa entre dispositivos eliminada, lógica escrita em um software programação baixado em um hardware. Tão integrado que facilmente obtém informação em qualquer lugar.

Garantir que desenvolvedor criando HMI embutido possa criar grupos de usuários e credenciais é crítico. Permite programador criar instância customizada do HMI, dependendo do usuário.

Facilidade fluxo informação dentro da máquina importante, mas também entre máquinas. Padrão IEC 61131-3 garante que máquina desenvolvida por um fabricante fala mesma linguagem de outra. Beneficia integradores: mais fácil fazer dois sistemas diferentes conversarem, passo necessário para IIoT. Organizações como OMAC [Organization for Machine Automation and Control], promovendo padrão PackML, levam IEC 61131-3 ao próximo nível: não só recomendam como sistema deve ser programado, mas desenvolvem conjunto padrão de tags que máquinas devem disponibilizar a outras na rede.

E dispositivos de baixo nível, como válvulas pneumáticas e sensores posição? Não tudo deveria ser parte do IoT?

Desafio: pegar dados de dispositivos baixo nível e transformar em informação útil. Abordagem: processar no nível destes dispositivos e enviar resultados via barramento controle alto desempenho ou direto à nuvem. Abordagem cara e não ajuda reunir/centralizar dados. Alternativamente, vemos enorme crescimento popularidade IO-Link, protocolo serial que coleta dados básicos de sensores temperatura, solenoides, manifolds válvulas pneumáticas, etc., sem overhead caro.

Mantendo barramento simples, dados coletados e tornados úteis por processamento no PAC ou PLC que existe em todo sistema máquina. Com PAC, que também tem HMI embutido para publicação web, usuários pegam informação e colocam na rede, onde precisar. Imagine sistema pneumático com sensor monitorando som continuamente em decibéis. Único dado enviado a PAC IO-Link é dB atual. PAC pode ter blocos função IEC 61131-3 customizados desenvolvidos pelo fabricante que funcionam em múltiplos controladores. Blocos verificam padrão estranho no ruído: 'Ah, pode haver vazamento.' Programador pega alerta e envia mensagem a usuário nível manutenção do HMI antes da falha pneumática.

Como informação vai da máquina à nuvem, e sobre software envolvido?

Ainda grande divisão entre chão fábrica e TI. Especialmente empresas manufatureiras com múltiplas instalações em vários estados/países, armazenar dados em servidor externo ou nuvem é ideal. Do lado software, fabricantes componentes precisam tornar vida construtores máquinas fácil ao trabalhar com TI.

Maioria construtores máquinas confortável programando PLC/PAC em IEC ou linguagens similares, então empresas devem buscar fabricantes com abordagem integrada controle máquina para tornar fluxo informação fácil mas também fácil compartilhar a servidores TI. Outro padrão vindo da Europa: OPC-UA [OPC Unified Architecture]. Protocolo cliente-servidor expandiu significativamente, permitindo forma universal transferir dados máquina-máquina, máquina-SCADA, ou máquina-servidor. Por flexibilidade, OPC-UA rapidamente torna padrão IoT. Busque fornecedores com ferramentas software embutidas para criar conexão OPC-UA em poucos cliques e permitir desenvolvedores compartilhar dados simplesmente compartilhando algumas tags dentro programa IEC 61131-3. Uma vez acessível em servidor, TI cuida do resto.

Informação útil na nuvem? Como dado crítico chega às mãos do operador, no chão fábrica?

Depende do caso uso. Quem pensa IIoT — operador máquina, construtor OEM, dono fábrica — deve primeiro desenvolver caso uso. Gerente chão fábrica pode querer informação overall equipment effectiveness [OEE]. Tipo informação geralmente não compartilhada com público amplo, melhor usar servidor interno. Mas gerentes frequentemente longe da máquina, ou não em mesas, mas precisam ver OEE. Caso uso direciona solução: se máquina tem HMI embutido com web server, usuário conecta via iOS ou Android, entra credenciais, vê OEE máquinas, sem nuvem externa. Rede in-factory chamada 'fog' computing.

Outro exemplo: agente compras monitora dados rendimento múltiplas linhas fábrica em múltiplas localizações. Servidor externo única resposta. Minimizar risco expor info sensível, programa publica apenas saída total, não rendimentos. Embora exija servidor nuvem, ilustra necessidade contenção ao enviar dados a servidor externo: geralmente menos seguro que rede interna/'fog', e maioria planos cobra para enviar/armazenar dados nuvem externa.

Marketing fez ótimo trabalho promovendo Indústria 4.0, mas cada usuário deve dar passo atrás e perguntar: 'Como posso usar a informação?' Nuvem pode não ser tão necessária quanto pensa.

Toda essa conectividade não aumenta custo?

Pode, mas não tem que. Onde fica caro: 3-4 anos futuro, quando empresa pronta para IoT, mas especificou dispositivos que dificultam/impossibilitam comunicar via web server ou OPC-UA, ou escolheu design fragmentado tradicional em vez de PACs single-machine que tornam fluxo dados significativamente mais fácil. Mitigar erro: comprar sensores incrivelmente caros que vão controle temperatura direto à nuvem externa, bypassing outros dispositivos máquina. Daí, programar camada customizada ou site usando software outro para tornar dados úteis. Não quer ser esse cara.

Em vez, implemente IIoT inteligentemente: faça parte do design máquina no Dia Um. Se construindo nova aplicação, posição perfeita para transição, mesmo se não algo que organização considera agora. Escolhas hoje economizam centenas milhares dólares depois.

Também, selecione dispositivos baixo nível suportando barramentos como IO-Link para obter dados deles acessivelmente. Use protocolos padrão custo-efetivos permitindo usar dados de muitas fontes. Use único software programação em único controlador para simplificar. Certifique-se que controlador máquina tem habilidade relacionamento cliente-servidor sem necessariamente exigir gateway adicional. Assim, se precisar rotear informação a diferentes locais, faz direto no programa IEC-based. Não esqueça fog computing. Se PLC tem HMI embutido web-server capable, pode satisfazer todos casos uso IIoT sem nuvem. E se precisar, certifique-se controlador tem software que facilita compartilhar a servidor OPC-UA, para TI fazer o que TI faz melhor.

Escolhas inteligentes tornam conversão IIoT muito acessível, mas escolhas precisam ser feitas agora.