terça-feira, 18 de maio de 2010

Softwares Supervisórios - todos são ótimos!!! Mas em quê?

Característica-padrão de todos os supervisórios: são simples, completos e fáceis de usar. Nunca dão pau, nem é necessária muita experiência para programar. E um é melhor que o outro, sempre.

Bem, sendo assim, como escolher um software de automação bom e confiável? Dependendo do seu critério, a resposta tende a um ou outro software. Simples assim.

Mas então como selecionar um software para atender às suas necessidades? Segue abaixo um guia de seleção de softwares supervisórios.

1 - Conectividade: seu supervisório terá de se comunicar com diferentes tipos de protocolos?

Se a resposta for sim, verifique se o fabricante dos equipamentos mais comuns tem os drivers para os outros protocolos. Por exemplo, você tem que ligar 3 PLCs Allen Bradley a 2 medidores de energia que falam em Modbus via supervisório. Não adianta tentar o RSView ou FactoryTalk, pois ele não vai falar com os medidores. Ah, mas o cliente quer esse.... não tem problema (para tudo existe solução), mas se puder escolher, selecione pela conectividade sempre que possível.

2 - Programação ou configuração: você é um ás em VBA ou VBScript ou prefere configurar propriedades?

Se a resposta for "gosto de programar" ou ainda "tenho tempo suficiente para programar esse projeto", selecione uma ferramenta que ofereça facilidades de programação. Estão entre essas o Elipse E3, o iFIX, o novíssimo Pulse da Afcon, para citar alguns.
Se você prefere "clique-e-mostre", parta para softwares que exijam menos programação. Entre eles o P-CIM, o Citect, o Cimplicity e o Indusoft.

3 - Flexibilidade x Objetos prontos

Outra característica necessária, mas que traz dúvidas: quão flexível a ferramenta deve ser ao desenhar telas ou históricos. Em alguns softwares se faz necessário um malabarismo para se criar algo novo, mas a biblioteca te deixa tranquilo quanto ao que está disponível. E existem bibliotecas e bibliotecas, digamos.
A biblioteca Symbol Factory faz parte de alguns pacotes de supervisório. Por exemplo, no Pulse e nos Elipse Scada e E3 ela está presente. Mas no Pulse, quando você puxa algo da biblioteca, já tem os links preparados para serem animados (por exemplo, um gauge vem com a propriedade Ângulo pronta para ser ligada ao tag). Já no E3, é necessário "mudar para símbolo, desagrupar, selecionar o ponteiro, agrupar, criar o link com o tag, agrupar tudo de novo" e pronto. Qual terá o resultado mais rápido durante o desenvolvimento?

4 - Select * from tabela where date < sysdate() - 7

Você conhece banco de dados e sabe como sintonizar as tabelas para melhor desempenho? Bem, se não é sua especialidade, pergunte: vou mesmo precisar aprender isso para que meu sistema continue executando depois de 3 meses?
Existem ferramentas que dependem de bancos de dados minimamente sintonizados para funcionar. O Elipse E3 é garantido que precise de MS SQL Server: o Access dá pau depois de algum tempo rodando, isso é fato. Caberá a você desenvolvedor cuidar de aprender SQL, chaves primárias e índices. Boa sorte com a leitura no Google ou no site da Elipse (eu mesmo escrevi alguns artigos sobre isso lá).
Já outros, como o Pulse, utilizam banco de dados, mas instalam automaticamente o software, configura o usuário necessário, cria e gerencia as tabelas que serão utilizadas pelos seus históricos. Muito mais fácil.
Outros ainda, atendem suficientemente bem sem necessitar de um banco de dados. Formatos proprietários funcionam bem quando existem configurações de segurança de arquivos, para evitar problemas de perda de arquivos, por exemplo. Entre esses softwares estão o P-CIM, versões mais antigas do Intouch, o iFIX, o RSView e por aí vai.
A pergunta final é: meu projeto precisa de um banco de dados? Ou um formato de arquivos seguro dá conta do recado?

5 - Recursos para agilizar o desenvolvimento

Existem recursos construídos para facilitar e agilizar o desenvolvimento de projetos. Mas não vamos ficar dependentes deles, certo?
Um recurso interessante que existe no P-CIM e no PULSE é o conceito de células. Vamos dizer que você tenha muitos motores na sua planta, com a velocidade sendo mostrada na tela. Ao posicionar o motor na tela e linkar um tag para mostrar velocidade, você pode criar uma "célula". Toda vez que copiar essa célula, o software lembrará qual o link que foi feito e você poderá mudar o tag para o novo motor. Assim, você replica os tags e motores com o mínimo de esforço.
Repita a operação no E3 fazendo o seguinte: crie um XObject e sua lista de propriedades. Crie um XControl e link com o Xobject. No XControl, faça o link com a propriedade desejada. Salve e "Registre a bibioteca". Depois crie instâncias do XObject no servidor e do XCOntrol na tela. Link os tags às propriedades do XObject e link os XObjects ao XControls na tela. Salve tudo e execute para ver o resultado. Ligue para o suporte. Pronto, funcionou. 

Os Dynamos do iFIX funcionam de maneira bem parecida às células do Pulse e são recursos recentes do software.

6 - Documentação

Algumas pessoas se preocupam com a documentação do software estar em português. Isso faz diferença para quem está começando a usar a ferramenta, realmente. Mas de todos os grandes fornecedores de automação, qual deles traduz os manuais para nossa língua? E quantas vezes você precisou do inglês para sanar dúvidas. Então, para quem já está na chuva, um pingo a mais não machuca.
O importante, em todo caso, é que a documentação seja efetiva: ela responde ao que eu preciso responder? Encontro fontes ou referências suficientes para utilizar a ferramenta? Se sim, não preciso de translation...

7 - Relacionamento com o fabricante

Sabe aquela do "não é uma Brastemp, mas...". Um dos pontos a ser questionado é: todos são legais quando te vendem (quase todos, por sinal), mas na hora que a comunicação trava, você está em campo com o cliente fungando o cangote e você liga para o fabricante, qual a reação dele com você?
Não importa com os outros: se o cara é bacana com todo mundo, mas do seu nome ele não gosta, não se preocupe. Outros supervisórios podem te ajudar!

De qualquer forma, ainda vale a máxima: o cliente é quem tem razão e você só quer defender o seu. Se o cara quer "aquele", corra atrás e fique amigo do suporte "daquela" empresa.

4 comentários:

  1. Olá Paulo!! Descobri seu blog hj, muito bom por sinal!!

    ResponderExcluir
  2. Valeu, João Diniz! Obrigado pelo comentário e volte sempre. Vou tentar atualizar o site sempre que possível!!

    ResponderExcluir
  3. Boa dicas....
    Na minha experiencia com supervisorios que e pouca:
    Elipse Scada: Muito bom intuitivo, porem simples
    Indusoft: Complexo p/ algumas funcoes (nao intuitivo)
    Wincc: Caro , mas otima ferramenta menus etc...
    E3:Da pau em funcoes simples como botoes, nao tao intuitivo. esqueceram o que o Scada tinha de bom como janelas com todas as propriedades da funcao (botao por exemplo.Boa propriedade de animacao.
    Espero ter ajudado....Valeu

    ResponderExcluir
  4. Trabalho com o Elipse E3 a 4 anos e também sou desenvolvedor Java. Alguns dos pontos positivos do E3 são a vasta quantidade de drivers, conexão nativa com bancos, facilidade para construir animações e replicá-las, bastante intuitivo para desenvolvedores iniciantes. Qualquer necessidade de integração com camadas superiores, ou outras plataformas, podem ser feitas criando DLL's clientes de webservices, registrá-las e chamá-las de dentro do próprio código.

    Aplicações simples, com poucos tags, podem muito bem ser feitas com Java. Porém, o conjunto de funcionalidades do E3 pode acabar sendo vantajoso, conforme a aplicação toma dimensões maiores.

    Só que desenvolver a aplicação no E3 não é problema. O problema é mantê-la, incluir novas funcionalidades, melhorá-la. Não existe depurador de scripts. O depurador do Windows só funciona no XP - foi descontinuado no 7. Você sabe que o script está dando pau, e tem que ficar caçando o erro nos logs. Isso é horrível! Não tem compilação em tempo real, que é uma mão na roda... Se você digita ponto, ele não lista as propriedades/métodos. E principalmente, o conceito de refactoring não existe. Isso é "O Caos". Se você renomear ou excluir alguma coisa, tem que caçar em toda a aplicação. E não me venha com "global replace"... Você pode controlar versionamento com Tortoise, mas não tem nenhuma ferramenta dentro do próprio E3 que facilite isso. Outra coisa é que os scripts são todos orientados a eventos. É tudo "onChange", "onClick"... Você não consegue chamar os métodos de verdade, dispará-los, sempre precisa ficar criando eventos OnChange. Foi a gambiarra (DocStringChange) que encontrei para poder reutilizar código e poder chamá-lo de outros objetos.

    Tá certo que as desvantagens que citei acima fazem sentido se você prefere código ao invés de ser um "arrastador de mouse". Acho que uma ferramenta de supervisório deve atender ambos os públicos para ser completa. Na minha opinião, a construção da aplicação com ênfase no código sempre será mais ágil e com alcance maior que qualquer método visual.

    ResponderExcluir