Plataforma aberta para implementar requisitos atuais e futuros
Phoenix Contact S.A., Portugal Tel.: +351 219 112 760 · Fax: +351 219 112 769 www.phoenixcontact.pt
Michael Gulsch, Business Development, Phoenix Contact Electronics GmbH, Alemanha Carlos Coutinho, Marketing and Product Manager
Num mundo de mudanças rápidas em que um número crescente de coisas que estão interligadas entre si, a automação industrial está a passar por uma transformação fundamental. Estruturas clássicas estão a evoluir para sistemas ciberfísicos. Soluções de automação orientadas para o futuro têm, portanto, de ser flexíveis, abertas e interligadas em rede. A tecnologia PLCnext oferece uma plataforma que está completamente aberta a novos níveis de liberdade.
robótica
104
informação técnico-comercial
Automação sem limites.
Figura 1. Arquitetura de automação clássica com ambiente de runtime específico de uma marca e sem acesso à interface API do sistema operativo.
Para explicar o que faz esta plataforma tão flexível, precisamos de regressar às arquiteturas dos sistemas de automação clássicos. Estes são moldados a sistemas de runtime proprietários. Baseados num sistema operativo, os sistemas de runtime específicos de marca correm programas em tempo real, isto é executam a tarefa de scheduling. São também responsáveis pela troca consistente dos valores das variáveis do processo automático. A vantagem deste tipo de arquitetura é que o programador não tem de intervir no sistema operativo. Se as alterações são feitas sobre o sistema operativo como resultado de uma atualização, a execução do programa não é afetada. De facto, as alterações do sistema operativo são
integradas pelas correspondentes adaptações que a marca faz ao seu ambiente de runtime. No entanto esta vantagem particular dos sistemas de automação clássicos contém certas desvantagens no atual mundo da tecnologia de automação (Figura 1). É impossível ou extremamente difícil ir ao encontro dos requisitos das aplicações orientadas para o futuro, recorrendo à arquitetura descrita acima. Exemplos disto incluem a integração do stack do protocolo MQTT, a ligação a uma base de dados ou a interatuação com a plataforma Node.js ao nível do autómato. Isto sucede porque as bibliotecas existentes sob a forma de DLL (Dynamic Link Library) para sistemas baseados em Windows
ou objetos partilhados (.so) em sistemas Linux não podem ser prontamente integrados em sistemas clássicos. Em muitos casos, estes sistemas exigem o acesso a funções da interface API do sistema operativo. No entanto isto é encapsulado pelo ambiente de runtime pelas razões mencionadas anteriormente. A marca do autómato teria, portanto, de disponibilizar as funções do runtime. Adicionalmente, o sistema clássico teria de ser capaz de integrar uma DLL ou um “.so”.
ABORDAGENS PARA OTIMIZAR SISTEMAS CLÁSSICOS DE AUTOMAÇÃO TÊM AINDA FALHAS Contra esta limitação surgiram várias soluções para os sistemas clássicos de automação. A mais simples, mas mais onerosa, é manter a arquitetura clássica na sua forma existente. O programador recebe um compilador add on para a software de programação como o Visual Studio ou o Eclipse, que compila um programa destinado a correr no runtime específico de cada marca. Isto permite aos programadores desenvolver programas numa linguagem de alto nível e criar um código executável que pode normalmente ser inserido como bloco de função normalizado, conforme a Norma IEC 61131. No entanto, a desvantagem persiste na medida em que o programador apenas tem acesso às funções do sistema operativo que a marca disponibiliza para o seu sistema de runtime. Consequentemente, o programador pode ter de esperar por uma atualização do autómato para implementar um determinado funcionamento específico (Figura 2). Outra abordagem alternativa passa pelo programador ter acesso a um hardware completamente aberto, que é normalmente baseado nos sistemas