Para realizar comunicação com equipamentos, a sequência a ser adotada em praticamente todos os supervisórios é semelhante. Desse modo, antes de comentar algum supervisório específico, vou abordar essa sequência para que seja mais simples entender quando chegar a vez de comentar cada um dos softwares específicos.
Vou padronizar os posts de comunicação para facilitar a comparação entre diferentes softwares e cada item abaixo será um modelo do que será discutido posteriormente.
Informações preliminares
Algumas informações são importantes quando se fala em drivers, ou quando se questiona um fabricante se seu software se comunica com algum equipamento. Ou mesmo quando a resposta do fabricante é um "sim" desejável, mas cheio de "senões" questionáveis.
Ao iniciar a conversa com um fabricante, é necessário verificar alguns pontos, que considero importantes:
- Existe um driver para o equipamento que pretendo comunicar?
Um fator importante para um software supervisório é a quantidade de equipamentos com que ele se comunica. Imagine desenvolver um projeto, instalá-lo, usá-lo por um período e na primeira ampliação do sistema, ter de trocar e começar tudo de novo pois não existe um driver disponível? Isso não faz muito sentido, embora possa ser remediado com outras perguntas, como as comentadas abaixo.
- Esse driver (se existir) está atualizado e completo?
Ótimo, você conseguiu um driver para uma rede de seu interesse, mas na hora de comunicar, entra alguém do suporte na linha e diz que "esse driver não funciona com esse equipamento" ou então "precisamos finalizar o driver pois o protocolo só foi feito parcialmente". Isso pode aumentar seu custo depois de iniciado o projeto ou deixá-lo aguardando por um prazo que não faz sentido no seu projeto. Se for iniciar um projeto com uma ferramenta desconhecida (e portanto uma empresa desconhecida para você), exija comunicações por escrito nesse ponto.
- Qual a capacidade máxima do driver em termos de equipamentos?
Protocolos têm padrão para o número máximo de equipamentos em uma rede. Modbus por exemplo, suporta até 254 escravos. Mas e o driver de seu supervisório: ele suporta todas as portas seriais usadas em seu sistema de rádio ou celular?
- Qual a quantidade de redes diferentes que posso acessar com esse driver?
Outra dúvida: quantas redes de equipamentos meu equipamento pode se comunicar, se eles estiverem pendurados em mais de um varal RS-485? Usar mais de uma cópia do driver pode ser uma solução, mas é a ideal para você?
- Qual a quantidade de IPs de uma mesma rede posso acessar com esse driver?
Problema bastante comum nos dias de hoje, quantos IPs seu driver pode acessar? Se seu PLC tiver um endereço IP próprio, em uma rede de 5 PLCs quantos drivers deverão ser utilizados?
- Se não existir o driver, qual a política de desenvolvimento de drivers?
Existe uma equipe de desenvolvimento de drivers dedicada a novos protocolos? Os últimos prazos para desenvolvimento de drivers foram cumpridos? Existe um custo para o desenvolvimento ou isso é feito dentro do escopo das licenças de software?
- Existe um SDK para desenvolvimento de drivers de maneira gratuita e irrestrita?
Se você tem alguém na equipe que programa C/C++ você conseguiria desenvolver seu próprio driver, se o fabricante disponibilizar um SDK. E se houver esse SDK, ele é o mais recente em termos de tecnologia existente no fabricante?
- Existe suporte para o uso do SDK disponibilizado?
Se houverem dúvidas com o uso do SDK, existe um canal para eliminar dúvidas?
- Tags internas contam como pontos para determinação de licenças de execução?
Ponto importantíssimo, reflete a organização e o cuidado que se deverá tomar na hora da especificação da licença de execução. Ainda assim, só será possível contabilizar tags internos ao final do desenvolvimento.
- O custo dos drivers está embutido na licença do software ou drivers são cobrados à parte, conforme forem necessários?
Outro ponto importantíssimo pois reflete custos: os drivers são livres para serem usados em qualquer aplicação ou trazem um custo adicional ao software que você não esperava ter quando especificou sua licença? Esse ponto é reflexo das questões sobre a capacidade máxima do driver (quanto a redes, IPs e quantidade de equipamentos possíveis).
O primeiro passo para colocar a comunicação em execução é a configuração de drivers. As perguntas anteriores trarão o reflexo imediato nessas etapas. Como cada software tem sua lógica de configuração, serão expostas aqui as etapas para configuração de um driver padrão Modbus TCP, com todas as possibilidades existentes em cada uma das famílias a serem apresentadas.
Configuração de Tags
Uma vez configurados os drivers de comunicação, começa-se a construir a base de tags. E como essa configuração é distinta entre os supervisórios, mais uma vez os passos serão seguidos e apresentados para construção do projeto.
Certo, não queremos simplesmente comparar e dizer qual o melhor, mas... Se são diferentes, uns têm características melhores que outros em certos pontos. É aqui que vamos discutir essas vantagens.
Desvantagens do Modelo de Comunicação
O que te fará perder a cabeça ao utilizar o software? Qual a justificativa furada para uma falha do software que você precisará saber? Nessa seção, as deficiências serão comentadas comparativamente a outras ferramentas.
Conclusões
Considerando que programadores são diferentes e têm preferências por diferentes ferramentas, as soluções para uma mesma questão podem ser muito diferentes. Por esse motivo, os próximos posts serão interessantes ao comparar diferentes métodos de comunicação.
Nenhum comentário:
Postar um comentário