Memórias dolorosas de simulações de PLC

Esta declaração volumosa de uma dissertação do Sr. Roland Schulz de 2002 resume muito bem no todo.

Resumindo:"Tentar e testar ajuda a encontrar erros".

Agora, não estou escrevendo aqui sobre a simulação de plantas de produção inteiras, mas dividindo o princípio ainda mais em unidades individuais (componentes), como programas de automação ou projetos de usuários.

No passado, como jovem funcionário da Phoenix Contact, também tive que aprender a programar e ficaria feliz com uma simulação do controlador. Simplesmente para saber mais sobre o funcionamento e função dos blocos ou programas por "tentativa e erro". Infelizmente, ele não existia naquela época e a simulação de PLC que se seguiu foi muito limitada. O código IEC61131-3 poderia ser bem simulado, mas faltava o suporte de dispositivos especiais ou simplesmente o comportamento diferente do código entre os sistemas baseados em Intel e ARM ou Motorola.



Com estes pensamentos em mente e as memórias da dor que tivemos com a simulação "clássica" de um PLC, partimos para encontrar realmente algo com valor agregado sem criar grandes esforços. Esforços por um lado no desenvolvimento de uma simulação e esforços que poderiam surgir posteriormente na utilização da mesma.

Como usuário, quero poder enviar meu projeto para um PLC ou para uma simulação, no máximo com um clique do mouse. Não quero prestar atenção em arquiteturas de processador, e certamente não quero ser forçado a esconder ou, pior ainda, remover funções no meu código que não são suportadas pela simulação.

O que poderia ser mais óbvio do que usar o firmware real na simulação, que também é usado no hardware de controle real? E foi exatamente isso que aconteceu.

Hoje em dia existem emulações de sistema completas que não apenas permitem executar vários sistemas operacionais no Windows. Eles também permitem a emulação de várias arquiteturas de processador e suas características.

Não é segredo que nossos controladores são baseados em Linux. Mas é importante para o desenvolvimento do código que aqui também sejam usadas diferentes arquiteturas de processador.

Na engenharia, no nosso caso o PLCnext Engineer, o cliente deve poder escolher entre o endereço IP do controlador ou a simulação - com um clique do mouse sem se preocupar com outras adaptações de código ou compatibilidade de código binário.

O que saiu desses pensamentos?

Encontramos a emulação do sistema QEMU e a usamos para simular nossos controladores. QEMU é uma "emulação de máquina de código aberto" e oferece exatamente o que estávamos procurando.

"Apenas" execute o firmware nele e o QEMU emula o sistema Linux completo da PLCnext Technology, incluindo a arquitetura do processador ARM de alguns controladores PLCnext -- e a simulação PLCnext nasceu. É certo que incluímos algumas pequenas limitações. A comunicação PROFINET ou outros protocolos de comunicação estão desabilitados. Mas o servidor OPC UA, por exemplo, não é afetado.

No entanto, todas as características especiais da PLCnext Technology puderam ser preservadas. Assim, também posso enviar meus programas e componentes C/C++, C# ou Matlab Simulink para a simulação. Também os APPs, que posso encontrar para determinados aplicativos na Store, podem ser trazidos para a execução.

Algumas outras limitações são óbvias - o determinismo não é esperado de um sistema simulado. E dependendo da carga do meu sistema Windows, pode haver um ou outro watchdog na simulação do PLCnext. Mas, nesses casos, sempre posso dar ao processo de simulação uma prioridade mais alta no sistema Windows e, em seguida, os erros do watchdog são resolvidos rapidamente.

E agora finalmente tenho, uma simulação, ou talvez até dependendo da definição, uma emulação do meu controlador. Mas infelizmente tive que aprender a programar sem ele, e agora não programo tanto.