Projetos de software de controle inteligente e IHM ajudam os engenheiros a construir novas redes para a IIoT

Marissa Tucker, da Parker Hannifin, conversa com o editor sênior Patrick Waurzyniak

Eu daria um passo além do controlador de movimento e diria que o controlador de automação programável [PAC] desempenha o maior papel na IIoT. Isso porque, além de ter a lógica da máquina, os PACs incluem o controle de movimento como parte de suas rotinas e muitas vezes também possuem uma interface homem-máquina [IHM] incorporada. A beleza dessa abordagem é que o programa não precisa compartilhar tags entre dispositivos porque os componentes estão no mesmo dispositivo usando a mesma lógica. Isso não apenas reduz o tempo de programação, mas também facilita os recursos de IIoT.

Aqui está um exemplo:Erro de posição—que costumava ser muito específico para o controlador de movimento—é automaticamente acessível pela IHM incorporada. Se essa HMI incorporada tiver recursos de servidor web, o que muitas delas têm, a HMI pode enviar imediatamente um alerta para o operador local e também para um gerente da planta por e-mail ou SMS [serviço de mensagens curtas]. Isso é muito melhor do que a abordagem tradicional de fazer com que o controlador de movimento envie o erro para o CLP [controlador lógico programável], com o PLC tendo que processar os dados apenas para enviá-los para a HMI - que pode ou não ter um servidor web. Essa complexa transferência de dados entre dispositivos é eliminada, pois a lógica é escrita em um software de programação baixado em um dispositivo de hardware. É tão bem integrado que você pode obter informações facilmente em qualquer lugar.

Garantir que o desenvolvedor que cria a IHM incorporada possa criar diferentes grupos de usuários e credenciais é fundamental. Isso permite que o programador crie uma instância personalizada da HMI, dependendo do usuário.

A facilidade de fluxo de informações dentro da máquina é importante, mas também é importante a facilidade de fluxo de informações entre máquinas. O padrão de programação IEC 61131-3 garante que uma máquina desenvolvida por um fabricante fale a mesma linguagem usada por outro. Isso beneficia muito os integradores porque eles podem fazer com que dois sistemas de máquinas diferentes comuniquem-se com mais facilidade, um passo necessário para a IIoT. Organizações como a OMAC [Organization for Machine Automation and Control], que está promovendo o padrão PackML, estão levando a IEC 61131-3 para o próximo nível, não apenas recomendando como um sistema deve ser programado, mas também desenvolvendo um conjunto padrão de tags que máquinas deve disponibilizar para outras máquinas na rede.

E os dispositivos de baixo nível, como válvulas pneumáticas e sensores de posição? Tudo não deveria fazer parte da IoT?

O desafio está em pegar dados de dispositivos de baixo nível e transformá-los em informações úteis. Uma abordagem é fazer o processamento no nível desses dispositivos e enviar os resultados por um barramento de controle de alto desempenho ou diretamente para a nuvem. Essa é uma abordagem muito cara e não ajuda a coletar ou centralizar os dados. Alternativamente, estamos vendo um grande crescimento na popularidade do IO-Link, um protocolo baseado em série que pode coletar dados básicos de sensores de temperatura, solenóides, coletores de válvulas pneumáticas etc., sem despesas gerais.

Deixando o barramento simples, esses dados podem ser coletados e tornados úteis pelo processamento no PAC ou PLC que deve existir em cada sistema de máquina. Ao usar um PAC, que também possui uma IHM incorporada para publicação na Web, os usuários podem pegar essas informações e colocá-las na rede, onde quer que elas precisem ir. Imagine um sistema pneumático com um sensor monitorando continuamente o som em decibéis. Os únicos dados que precisam ser enviados para um PAC IO-Link são os dB atuais. O PAC pode ter blocos de função IEC 61131-3 personalizados desenvolvidos pelo fabricante que podem funcionar em vários controladores. Esses blocos de função podem verificar se há um padrão estranho no ruído, para dizer:'Ah, pode haver um vazamento'. .

Como as informações estão indo da máquina para a nuvem e o software envolvido?

Ainda existe uma grande divisão entre o chão de fábrica e a TI. Especialmente para empresas de manufatura com várias instalações em vários estados ou países, armazenar dados em um servidor externo ou na nuvem é o ideal. Do lado do software, os fabricantes de componentes precisam ajudar a tornar a vida dos construtores de máquinas o mais fácil possível ao trabalhar com TI.

A maioria dos fabricantes de máquinas se sente à vontade para programar um PLC ou PAC em IEC ou linguagens semelhantes, portanto, as empresas devem procurar fabricantes que adotem uma abordagem integrada ao controle de máquinas para facilitar o fluxo de informações mas que também facilitam o compartilhamento dessas informações com servidores de TI. Outro padrão que está sendo expulso da Europa é o OPC-UA [Arquitetura Unificada OPC]. Esse protocolo cliente-servidor se expandiu significativamente, permitindo uma maneira universal de transferir dados de máquina para máquina, máquina para SCADA ou máquina para servidor. Devido à sua flexibilidade, o OPC-UA está se tornando rapidamente o padrão de IoT. Procure fornecedores que tenham ferramentas de software integradas para criar facilmente uma conexão OPC-UA com apenas alguns cliques e permitir que os desenvolvedores compartilhem dados simplesmente compartilhando algumas tags em um programa IEC 61131-3. Assim que estiver acessível em um servidor, deixe que a TI cuide do resto.

As informações são úteis na nuvem? Como os dados críticos chegam às mãos do operador, no chão de fábrica?

Depende do caso de uso. Qualquer pessoa que esteja pensando na IIoT, seja operador de máquina, fabricante de máquina OEM ou proprietário de fábrica, deve primeiro desenvolver um caso de uso. Um gerente de chão de fábrica, por exemplo, pode querer informações sobre a eficácia geral do equipamento [OEE]. Esse tipo de informação geralmente não é algo que deve ser compartilhado com uma esfera pública mais ampla, por isso é melhor usar um servidor interno. No entanto, os gerentes de chão de fábrica muitas vezes podem estar longe da máquina, ou não em suas mesas, mas ainda precisam olhar para o OEE. O caso de uso impulsiona a solução:se a máquina tiver uma IHM incorporada com um servidor web, um usuário pode se conectar a ela a partir de uma plataforma iOS ou Android, inserir suas credenciais e visualizar o OEE das máquinas, sem necessidade de nuvem externa . Esta rede de fábrica é muitas vezes referida como computação de 'nevoeiro'.

Outro exemplo é um agente de compras que precisa monitorar os dados de rendimento de várias linhas de fábrica em vários locais. Um servidor externo é a única resposta. Para minimizar o risco de expor informações confidenciais da empresa, o programa pode publicar apenas a produção total, em vez dos rendimentos. Embora esta solução exija o uso de um servidor em nuvem, ela ilustra a necessidade de usar restrições ao enviar quaisquer dados para um servidor externo por dois motivos:geralmente, é menos seguro do que mantê-lo em uma rede interna ou 'neblina', e a maioria dos planos cobram das empresas o envio e armazenamento de dados para uma nuvem externa.

Os profissionais de marketing fizeram um ótimo trabalho promovendo a Indústria 4.0, mas cada usuário precisa dar um passo atrás e perguntar:'Como posso usar as informações?' A nuvem pode não ser tão necessária como você pode pensar.

Toda essa conectividade não está aumentando os custos?

Pode, mas não precisa. Onde fica caro é três ou quatro anos no futuro, quando sua empresa estiver pronta para IoT, mas você especificou dispositivos que dificultam ou impossibilitam a comunicação via servidor web ou OPC-UA, ou você escolheu um design tradicional fragmentado em vez de PACs de máquina única que facilitam significativamente o fluxo de dados. Para mitigar esse erro, você pode comprar sensores incrivelmente caros que vão do controle de temperatura direto para uma nuvem externa, ignorando todos os outros dispositivos da máquina. A partir daí, você terá que programar toda uma camada personalizada ou site usando o software de outra pessoa para tornar os dados úteis. Você não quer ser esse cara.

Em vez disso, implemente a IIoT de forma inteligente:torne-a parte do projeto da máquina no primeiro dia. Se você está criando um novo aplicativo, está na posição perfeita para fazer a transição, mesmo que não seja algo que sua organização esteja considerando agora. As escolhas que você faz hoje podem economizar centenas de milhares de dólares mais tarde.

Além disso, selecione dispositivos de baixo nível que suportem barramentos como IO-Link para que você possa obter dados deles de forma acessível. Use protocolos padrão que são econômicos e permitem que você use dados de várias fontes. Use um único software de programação em um único controlador para simplificar a programação. Certifique-se de que o controlador da máquina tenha capacidade para um relacionamento cliente-servidor sem necessariamente exigir outro gateway adicional. Dessa forma, se você precisar iniciar o roteamento de informações para locais diferentes, poderá fazê-lo corretamente em seu programa baseado em IEC. Não se esqueça da computação em neblina. Se o seu CLP tiver uma IHM incorporada que seja compatível com servidor da Web, você poderá satisfazer todos os seus casos de uso de IIoT sem o uso de uma nuvem. E se você precisar, certifique-se de que o controlador escolhido tenha um software que facilite o compartilhamento com um servidor OPC-UA, para que a TI possa fazer o que a TI faz de melhor.

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