Claro, o Engenheiro se orgulha de sua IHM, com destaque para o realismo no monitor, a coordenação de cores nos dados e a maestria na navegação… E depois há o Gerente da Fábrica, deslumbrando KPIs em seu
dashboarde verificando como sua planta está efetivamente funcionando com a implantação da nova solução de MES. Os sistemas supervisórios, historiadores e analisadores de dados recebem todo o crédito quandose
evita uma crise no controle da planta. Alguém já pensou em agradecer ao humilde driver de comunicação? Sem dados, a IHM é apenas uma imagem bonita e as melhores análises do mundo são apenas ideias sem qualquer base na realidade. E você gasta dezenas ou centenas de milhares de reais nestes sistemas, enquanto o orçamento para o driverde comunicação nem sequer entra nas folhas de especificação dos sistemas…

A verdade é que o driver de comunicação é um dos componentes mais importantes de qualquer sistema de automação. É o sangue que alimenta o sistema. As artérias e veias dos drivers de comunicação alcançam
todas as áreas da planta, enviam e recebem dados, garantindo a capacidade incansável e eficiente de adquirir, analisar e adaptar-se às diferentes situações que aparecem. Ao longo dos anos, os drivers
mudaram. No início existia o DOS. Vamos ser breves – sabemos que isto pode ser antes da sua época… Os drivers são a base de qualquer aplicação. Se você estivesse usando uma IHM, o driver de comunicação era
fornecido pelo fabricante da IHM e só funcionaria com aquela IHM. Depois veio o Windows com tecnologia para compartilhar informações entre aplicativos, através de DDE (Dynamic Data Exchange). Ainda que a
tecnologia estivesse progredindo, o investimento feito até então no desenvolvimento de drivers personalizados havia sido grande demais para ser jogado fora. Em 1995, a OPC Foundation foi criada coma ideia de aproveitar as mais recentes tecnologias daMicrosoft para desenvolver um padrão de interoperabilidade que permitisse que a troca de dados entre aplicativos de automação. Os drivers foram muito beneficiados. Finalmente havia aparecido um padrão de alto desempenho que os drivers puderam utilizar para a conectividade com softwares de maisde um fornecedor.

Os fornecedores adotaram rapidamente os padrões OPC. O conjunto de drivers para seus aplicativos foi extensamente ampliado com as novas interfaces OPC. Seus aplicativos clientes passaram a incorporar o OPC para que pudessem aproveitar dados de drivers e produtos de terceiros. Os desenvolvedores independentes de drivers puderam encontrar um mercado mais amplo para os seus drivers, normalmente desenvolvidos como parte de um esforço de integração a um aplicativo específico. E assim, nasceu uma indústria.

Apesar do passo ter sido dado na direção certa, este não era um modelo perfeito. Enquanto existia um padrão para a interoperabilidade, cabia aos desenvolvedores aderir a esse padrão e testar essa interoperabilidade – ao ponto de alcançar o nível de uma auto-certificação.Os drivers desenvolvidos por diferentes empresas têm diferentes interfaces para o usuário, métodos de operação, diagnósticos e etc.Um driver desenvolvido para um aplicativo específico não estará, necessariamente, otimizado para trabalhar com outros aplicativos. E, a menos que haja um volume significativo de venda deste determinado driver, o custo a longo prazo com a sua manutenção pode tornar-se proibitivo para os fabricantes de equipamentos. Todos esses fatores resultaram em um mercado de drivers com diferentes níveis de qualidade, desempenho, funcionalidade e confiabilidade geral. Mesmo os drivers dos principais fornecedores, oferecidos em conjunto com seus softwares IHM / SCADA e Historiadores, podem sofrer de falta de atenção e de aperfeiçoamento constante devido aos altos custos de manutenção do driver. Muitas empresas optaram por migrar para um modelo terceirizado de driver, aproveitando a escala e a experiência industrial de empresas dedicadas ao desenvolvimento de drivers.

Os novos padrões melhoraram a interoperabilidade dodriver. Em fevereiro de 2008, a OPC Foundation introduziu um novo nível de certificação. Onde, no passado, ferramentas de teste de interoperabilidade entre fornecedores eram o único caminho para a certificação, através de um processo de auto-certificação, hoje existe um laboratório de testes autorizado pela OPCFoundation na Alemanha. Este laboratório realiza testes
exaustivos com o driver para verificar todos os aspectos de conformidade do padrão OPC, resultando inclusive em recomendações quanto à sua instalação e usabilidade. No final, se aprovados, os fornecedores podem usar o logo “Certified OPC Compliant”. Os usuários devem procurar o logotipo da certificação por uma série de razões. Ele mostra que o produto atingiu um nível de qualidade esperado. E mostra também que a empresa se esforçou para atingir esse nível de qualidade, indicando que o driver tem e terá suporte técnico agora e no futuro.

Mas quais as características que você deve procurarem um driver? Não se trata apenas da questão de transferir dado do ponto A para o ponto B. Os drivers precisam ser projetados para ter alto desempenho, facilidade de uso, confiabilidade e operação adequada em caso de interrupção ou falha no sistema. Sendo este último ponto o mais importante e muitas vezes esquecido no desenvolvimento dos drivers de comunicação. Vamos detalhar melhor estas questões aseguir.

O desempenho de um driver é vital para o bom funcionamento de um sistema e pode ser avaliado sob diferentes aspectos. (1) Em primeiro lugar, existe o desempenho do driver em função do método da aquisição dos dados. Os dispositivos de campo geralmente oferecem uma variedade de mecanismos para aquisição de suas informações. A leitura de um dadopode ser feita através de uma variável simples, através de blocos de dados ou então é possível receber atualizações de dados somente quando ocorre uma mudança em seu valor. Os melhores drivers irão oferecer todas estas opções para o usuário selecionar o método, de acordo com a necessidade. (2) Uma segunda forma de avaliar o desempenho do driver está na forma de priorização de suas tarefas. A escrita de informações nos dispositivos também tem que ser feita de forma eficiente e precisa ser garantida durante períodos de alto volume de tráfego na rede. Grandes demandas de leitura não podem impedir que o driver envie comandos de escrita para os dispositivos de campo. E a escrita não pode sempre sobrepor a leitura – por exemplo, escrever mil variáveis necessárias para uma mudança de uma receita poderia facilmente perturbar os processos normais de leitura – afetando a aquisição dos dados em um processo crítico de alta velocidade. (3) E por fim, as demandas de um driver de comunicação não devem impactar o funcionamento do computador no qual ele está sendo executado. Os aplicativos de automação geralmente têm centenas demilhares de tags, alguns com atualizações frequentes, outros apenas com atualizações esporádicas quando seus diagnósticos estão ativos. Os drivers devem ser otimizados para operação em multi-threads, alocando memória de forma eficaz e liberando-a
posteriormente a fim de não afetar outros processosque estão em execução no computador.

A facilidade de uso parece um requisito óbvio, mas nem sempre está presente nos drivers de comunicação. Os menus de configuração devem ser simples e autoexplicativos. Os menus de ajuda devem ser intuitivos em suas explicações e fornecer informações detalhadas, fáceis de serem encontradas.
Idealmente, o driver deve fornecer assistentes de configuração. Muitos equipamentos de campo já disponibilizam informações sobre sua configuração dentro de si mesmo, ou em um arquivo de programação para que o driver possa facilmente decodificar e seautoconfigurar. Muitas vezes, a configuração é feita através de assistentes e alguns drivers permitem que sejam configurados de forma automática. É raro umengenheiro configurar um driver através de menus. Um cenário mais provável é a configuração de parte deste processo, talvez uma das muitas linhas de produção, em seguida, usar ferramentas de copiar e colar, ou ferramentas de importação e exportação, para replicar a configuração com todos os ajustes necessários. O Excel ainda é a ferramenta mais utilizada para nomear de forma padrão uma lista de I/Os. Um desafio é conseguir conciliar configuraçãodos drivers de diferentes fabricantes de equipamentos. Como dito anteriormente, drivers de diferentes empresas se diferem completamente no que diz respeito à sua base de dados de configuração. Asolução para este problema só é possível optando por drivers de um único fornecedor que tenha uma biblioteca de drivers consistente, não apenas na forma de operação, mas em todas as suas ferramentas de configuração.

Por fim,confiabilidade é assunto obrigatório na indústria. Os sistemas deautomação são a base da infraestrutura mundial. Um lote de medicamentos pode valer milhões de dólares. O fracasso não é uma opção. Então, como um driver pode ser confiável? Com experiência, reutilização de códigos comprovados, testes com soluções para o setor, encontros sobre interoperabilidade e práticas internas adequadas para desenvolver e realizar um teste de qualidade antes de colocar um driver em produção. Infelizmente, muitos drivers nascem da necessidade de integração de um sistema, e depois passam diretamente a fazer parte de uma oferta padrão de comercialização. No mundo dos drivers de comunicação, o comprador deve ter cuidado. Um driver com um custo aparentemente bom pode chegar a custar até dez vezes mais para o usuário, se contabilizarmos o tempo gasto com a sua configuração e com os esforços de ajuste. O que acontece com a operação quando alguma coisa dá errado? É muito fácil atestar o bom desempenho de um driver trabalhando em condições ideais. Mas nem sempre se pode contar com as condições ideais. Existem diversos tipos de falha de comunicação, que muitas vezes não são previstos por um desenvolvedor ocasional de drivers. Os drivers podem comunicar através de redes sem fio e podem receber mensagens truncadas devido à estática, tempestades e etc. Os drivers podem estar comunicando com centenas de dispositivos, alguns em operação e outros não. A falha de um dispositivo não deve afetar a comunicação com os outros. Alguns softwares podem, inadvertidamente, tentar comunicar com o driver, atolando-o com mensagens não previstas. É preciso dar atenção paraos projetos dos buffersde comunicação, dos tempos limite e para as estratégias de varredura a fim demaximizar as operações sob condições adversas. Muitas vezes, os drivers possuem parâmetros de ajuste que permitem que um driver reduza a varredura de um
dispositivo em falha, a fim de minimizar, de forma geral, o impacto no sistema.

Os melhores drivers de comunicação são projetados para lidar com todas as demandas acima e fornecer essas funcionalidades, de forma consistente, para todos os protocolos, permitindo que os sistemas especialistas tenham uma única fonte de dados para se conectar com todos os dispositivos do chão de fábrica. Da próxima vez que estiver avaliando um driver, avalie como a sua aplicação seria executada na ocorrência de falha, e aloque orçamento de forma adequada para considerar o uso de um bom driver de comunicação.

Sobre os autores:
Tony Paine

Este artigo é de autoria da Exata Sistemas de Automação

~\\|//~
 -(o o)- RODRIGO SILVA

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s