quinta-feira, 28 de abril de 2011

Modelo de Comunicação - Elipse Scada

Informações preliminares
           A Elipse Software dispõe de cerca de 250 tipos diferentes de drivers, cobrindo uma grande parte dos protocolos utilizados em indústrias e no setor de energia. Entre esses drivers destacam-se aqueles que são praticamente exclusivos: os drivers para equipamentos nacionais (como CLPs Altus e Atos). 

           Para conseguir um driver Elipse é necessário ter um cadastro no site (moderado pelo suporte técnico deles) ou solicitar via e-mail para alguém do suporte técnico. 
           Dentre os drivers disponíveis, a Elipse os divide em três categorias (os nomes sou eu quem dei, mas a lógica é a deles):
           - Comuns: normalmente dependentes de porta serial RS232 ou Ethernet;
           - "Premium" ou "Especiais": servem para se comunicar com PLCs de marcas mais famosas (Siemens, Allen-Bradley, GE, por exemplo) ou dependem de interfaces específicas - como KTX da Allen-Bradley ou CP-5412A2, da Siemens;
           - Drivers Elétricos: drivers mais elaborados e com recursos utilizados no setor elétrico de potência.

           Além disso, existem alguns modelos diferentes de configuração de drivers, que serão mostrados a seguir. Mas para começar, podemos citar os drivers em grupos:
           - Drivers mais antigos: seguem a configuração padrão criada no Elipse Scada, onde toda a ajuda necessária depende de arquivos de ajuda que acompanham o driver;
           - Drivers intermediários: um pouco mais elaborados, mas que dependem fortemente do documento de ajuda (principalmente para configurar os tags);
            - Drivers baseados no IOkit: drivers com melhores recursos (e padrão entre eles), onde é possível configurar a maior parte do processo de maneira padronizada. A proporção deles no total de drivers tem aumentado, mas nem todos foram portados para o novo modelo (ou mantiveram a padronização de tags ao serem portados). 
           
Configuração de Drivers
             A configuração de drivers no Elipse Scada começa ao se abrir o Organizer e acessar o item "Drivers". Ao clicar nessa opção, surgem as opções padrão mostradas na Figura 1: Novo (para criar novo driver no aplicativo), Deletar para eliminar o driver (mas não os seus tags), Configurar (para abrir a aba de configuração do driver) ou Ajuda (que funciona apenas para drivers antigos que têm os arquivos de ajuda internamente a eles). 

Figura 1: Criação de Drivers no Scada

               Ao selecionar um novo driver, é solicitado que se selecione o arquivo .dll do driver, que não tem limitação de localização por parte do Scada, podendo ser colocado onde o programador melhor entender. 

           Uma vez instalado o driver (e dependendo do modelo e da idade do driver), o procedimento de configuração pode tomar um dos caminhos abaixo. 

Drivers mais antigos
Figura 2: Configuração via P1 a P4

            Os drivers clássicos da Elipse têm sua configuração dividida em parâmetros P1 a P4, cujo significado varia de driver a driver. O importante é que eles sempre se referem ao modo como o driver vai se comunicar e não a endereços (que serão mostrados adiante), ou seja, fala sobre o meio físico, velocidade de comunicação e etc. Um modelo de configuração de driver é mostrado abaixo:
            P1 - Porta COM (0=COM1, 1= COM2, etc);
            P2 -BaudRate (10 = 9600, 20 = 19200, etc.)  + Paridade (0 = None, 1 = Even, 2 = Odd)
            P3 - não usado
            P4 - timeout

            Fácil, simples e tranquilo de se enrolar, não?

Drivers intermediários
           São drivers nem tão recentes que trazem algumas facilidades adicionais na hora de se configurar o driver, como a Figura 3 mostra. 
Figura 3: Configuração de Drivers intermediários

                   Nesse padrão, ao clicar sobre o botão Extras é aberta uma janela com um conjunto de opções pré-definidas, eliminando a necessidade (pelo menos parcialmente) de se decodificar uma informação em P1 a P4. 

Drivers com o IOKit
                     Esses drivers são os mais recentes da Elipse e trazem recursos de flexibilidade muito bacanas na hora de se configurar o driver. Com ele, pode-se por exemplo, migrar de uma rede serial para Ethernet apenas configurando parâmetros do próprio driver, sem ter que substituí-lo, como normalmente era feito nos drivers mais antigos. A Figura 4 mostra as opções para um driver Modbus baseado no IOKit.
Figura 4: Driver Modbus no IOKit
                 O IOKit tem cinco abas que são padrão para todos os drivers: Setup, Serial, Ethernet, Modem e RAS, mais uma ou duas abas relacionadas ao protocolo. A aba Setup é responsável por habilitar uma das outras quatro, dependendo da escolha que se faça. 
                Um recurso interessante do IOKit é que alguns tratamentos de erros podem ser definidos aqui: como número de retentativas de conexão, timeout de comunicação de tags, timeout sem resposta do driver que precisa ser respeitado antes de nova tentativa de comunicação, configuração de logs, entre outras. É uma solução boa, muito embora nem todos os drivers suportem as quatro opções de configuração (serial, modem, ethernet e ras) ou os drivers mais antigos ao serem portados nem sempre respeitem a configuração de tags (o que inviabiliza a sua atualização sem horas de engenharia). 

                   Assim, uma vez configurado o driver por um dos três tipos comentados acima, é a hora de configurar os tags de comunicação. 


Configuração de Tags
                     Os tags de comunicação do Elipse Scada podem ser de dois tipos: tags PLC ou tags Bloco. Eles se diferenciam pela organização e funcionalidade: enquanto o tag PLC pega um endereço por consulta ao CLP os tags Bloco solicitam (como o nome diz) uma série de tags consecutivos. 
                      Antes de se configurar um tag, algumas considerações a serem feitas:
                      - Os tags de todos os tipos no Elipse Scada podem ser distribuídos por pastas de maneira a ser definida pelo programador;
                      - Todos os tipos de tags podem conviver em uma mesma pasta;
                      - Dessa forma, toda a organização do aplicativo fica por conta do programador, para o bem ou para o mal. 

               Voltando ao tópico, a configuração dos dois é semelhante, então vou comentar apenas o tag PLC, ressalvando as diferenças para o bloco, ok?

Figura 5: Configuração de Tags PLC

            Os tags PLC ao serem criados, precisam ser nomeados (conforme regra de nomes comuns a arquivos do Windows - sem as extensões, claro). Depois disso, o driver deve ser selecionado na lista ao lado do botão Ajuda. Para desativar o tag, basta não selecionar um driver.

                A seguir, o tag deve ser parametrizado pelos parâmetros N1 a N4 (se for um tag bloco, B1 a B4). Esses parâmetros, assim como os dos drivers, dependem de uma codificação para serem estabelecidos. Um exemplo de tag Modbus pode ser:
                   N1: número do PLC na rede;
                   N2: índice do endereço IP cadastrado no Extras;
                   N3: endereço do tag no PLC;
                   N4: não usado.

                Existem exemplos mais complexos conforme o protocolo torna-se mais complexo. Mas o principal é que para versões diferentes de drivers do mesmo protocolo (por exemplo, o próprio Modbus) os parâmetros N1/B1 a N4/B4 podem ser alterados. Portanto, mantenha junto ao projeto todos os arquivos de ajuda de drivers que forem úteis, pois no futuro você pode ficar na mão por não saber o significado de cada parâmetro. 

                    Uma pergunta que vem logo à cabeça: como posso acessar uma Word no PLC e usar os seus bits de maneira independente? 

                 O Elipse Scada tem uma maneira inteligente de fazer isso, como mostrado na Figura 6. Para acessar os bits de um tag, clica-se sobre o tag e depois em Acessar Bits. 

Figura 6: Seleção de Bits de um tag
                  Cada um dos bits criados poderá receber um nome, o que significa que você pode taguear um bit de maneira bem interessante. Mas isso não economiza tags na licença de runtime pois os tags bit também são contabilizados na licença.

                 Os parâmetros de leitura e escrita automática foram criadas para economizar recursos dos antigos computadores. Já a habilitação de leitura pelo scan determina se o tag será lido por varredura ou apenas por scripts. 

                   O parãmetro Scan é importante ainda, visto que muitos sistemas utilizam portas seriais a 9600 ou 19200 bps. Ajustar quais tags devem ter prioridade sobre outros é algo muito importante para o Elipse Scada funcionar corretamente.  

                 Os botões de Ler e Escrever são o único modo de testar se o tag está configurado corretamente. E isso só pode ser feito com apenas um tag por vez. 

Vantagens do Modelo do Elipse Scada
- No Elipse Scada é possível criar tags bit a partir de uma palavra lida do PLC ou outro equipamento de campo;

- Existe no Scada uma referência cruzada que ajuda bastante na construção do aplicativo (ao alterar o nome de um tag, por exemplo); 


Desvantagens do Modelo do Elipse Scada
- Drivers implicam em custos adicionais à licença de runtime;

- 3 Categorias distintas de drivers trazem ainda mais custos, quando se utilizam equipamentos de marcas top do mercado (como Siemens e Rockwell/Allen Bradley);

- Dependendo do projeto e da negociação, uma licença de drivers pode liberar até 4 drivers para execução: isso não é muito transparente para o usuário;

- Modelo baseado em parâmetros N1 a N4 implica em codificar ou decodificar o endereço recebido pelo PLC antes de implementar a comunicação;

- Excesso de padrões de configuração implica em ter de aprender cada driver e seus truques quando se vai iniciar um projeto novo. São pelo menos três modelos: drivers básicos com o SDK, básicos que usam o módulo IOKit e drivers especiais (alguns com IOkit e outros ainda com o SDK);

- No Scada não é possível fazer comunicação com todos os tags ao mesmo tempo, apenas testar a comunicação isoladamente em cada tag (através de botões Ler e Escrever). O resultado é que fica difícil verificar se a comunicação funciona corretamente quando todos os tags são acionados;

- Por ficarem "livres" no HD, é possível que falte o arquivo do driver no momento de transportar o projeto de um micro a outro. Fácil de resolver em ambiente de escritório, pode ser bem enrolado para resolver em campo. 

quarta-feira, 20 de abril de 2011

SupervisórioBR - 2 anos!!

Apesar de não ser muito movimentado no início, faz dois anos que o blog está no ar.

E podemos comemorar que nos últimos meses a coisa decolou: sempre a cada mês mais visitantes aparecem, e estamos completando um novo recorde esse mês.

Fiquem à vontade para comentar ou questionar quando discordarem de algo, ok?

Nesse período registramos visitantes brasileiros, claro. Mas também já veio gente de Israel, EUA, Canadá, Argentina, entre outros. Se todos falam português, não sei! Mas os nomes e produtos comentados no blog são internacionais, o que facilita a visita, certo?

Vamos lá! Ainda temos muito a fazer para tornar o blog uma referência em informações sobre SCADA, no Brasil e fora dele. Quem sabe?

segunda-feira, 18 de abril de 2011

Modelo de Comunicação - Sequência de Etapas

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). 

Configuração de Drivers
     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. 

Vantagens do Modelo de Comunicação
      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. 

quarta-feira, 6 de abril de 2011

Roteiros de Treinamento do Elipse Scada

Tenho o roteiro de treinamento e o manual de referência do Elipse Scada para download nos links abaixo.

Mas se você estiver pensando em começar agora, nem comece! O Elipse Scada está em decadência, pois o E3 assumiu a condição de melhor software da Elipse, já faz alguns anos.

Mas...
Se achou o Elipse E3 difícil e caro, tente o Indusoft. Ele é fácil e tem um preço inicial bacana, mas não tem todos os recursos do E3.

Se achou o E3 bom e caro, tente o Pulse. Ele tem um ótimo nível de recursos e um preço bacana.

É, concorrência é tudo! De qualquer modo, seguem os links para o Elipse Scada.

http://www.4shared.com/document/xtJJ3jHv/manual.html
http://www.4shared.com/document/cOTjEOA_/tutorial.html

Divirta-se!!!

Roteiros de Treinamento Indusoft

Consegui com a Indusoft duas versões do roteiro de treinamento no software. O primeiro está em português e o segundo em inglês.  O terceiro é um documento com informações genéricas da versão 6.1, que não é mais a atual.

Eles estão no link abaixo, onde pretendo colocar mais coisas assim que for possível. Por enquanto, seguem os links para os roteiros.

http://www.4shared.com/document/jVG1eQ1y/Apostila-PTBR.html

http://www.4shared.com/document/SxpvHHnq/Apostila-ENUS.html
http://www.4shared.com/document/aoE6D1gp/Datasheet_V61.html

Divirtam-se!