Olá,
Estamos observando a necessidade de adicionar cada vez mais protocolos no ScadaBR, e inclusive começam a aparecer pessoas que já desenvolvem software, e gostariam de adicionar seu próprio protocolo.
Normalmente a dica é configurar o CLP, PIC, etc. para o protocolo Modbus ou OPC; nem sempre isso é possível, por isso sempre buscamos incluir novidades como o ASCII e Mitsubishi Alpha2 dentro do ScadaBR, ou opções como o Siemens (libnodave) que pode ser utilizado com alguns truques.
Vou apresentar a seguir duas formas de adicionar qualquer protocolo no ScadaBR, uma eu chamo de “nativo” pois segue a estrutura original do mango/scadabr, e a outra chamo de “Genérico” pois é feita através de adaptações simples com outras linguagens. Sempre que vc tiver um protocolo já implementado em alguma linguagem, certamente isso pode ajudar e muito!
Idealmente, uma forma mais organizada de atacar essa questão dos protocolos seria termos um wiki para coletar e organizar os protocolos já existentes, para que possa se planejar a migração de cada um para funcionamento “Nativo” no ScadaBR. Esta idéia do wiki hoje está “em prototipagem”…
Seria muito interessante essa interação entre usuários para podermos traçar metas de atendimento a protocolos como o Profibus, Siemens S7, Isotcp, MPI/PPI, Canbus, DF1, UA, entre muitos outros que estão hoje “por aí” espalhados em outros projetos… com uma visão mais ampla e ajuda dos usuários, podemos priorizar os protocolos escolhendo primeiro entre aqueles que são mais pedidos, e também aqueles que exigem menor esforço para conclusão.
Estamos no aguardo do contato de quem quiser ajudar nesse processo, seja desenvolvendo um driver, ou patrocinando esse tipo de desenvolvimento.
abraço!
Victor
…
…
…
Plano A - Adicionando suporte a protocolos “nativos” (Java) para o ScadaBR
Requisitos:
- Programação Java básico /intermediário
- Protocolos de comunicação (básico = entender o mecanismo request/response);
- Noções de JSP e DWR - tecnologias web usadas no ScadaBR
Vantagens:
- Fica configurável por dentro da interface principal do ScadaBR
- Pode entrar para a próxima versão oficial do ScadaBR, ajudando outros usuários e também recebendo suporte e melhorias;
- Existe muita coisa já existente em Java e pode dar a sorte de encontrar boas implementações de protocolos.
Tarefas necessárias para cada protocolo:
- Extender as classes padrão VO e RT do ScadaBR (datasources)
- Implementar métodos “Write” e “doPoll” - são as funções mais importantes
- Implementar Integração com a Interface de Usuário (arquivos jsp)
- outras funções auxiliares (adicionar ID na lista de protocolos no init do mango/ScadaBR, funções importar/exportar, arquivos de tradução, e página de Help do protocolo)
- último passo - opcional - Integração via API - um datasource “redondinho” pode ser configurado via WebServices
Por onde começar:
Tudo que vc precisa (passo-a-passo da implantação) está neste documento aqui:
https://sites.google.com/a/certi.org.br/certi_scadabr/home/minicursos/scada
Após estudo detalhado do documento acima e início do desenvolvimento, dúvidas e discussões podem ser colocadas aqui no Fórum.
Plano B - Adicionando suporte a um protocolo “genérico” (Outras Linguagens) para o ScadaBR
Existem muitas (muitas mesmo) formas de tentar adaptar um protocolo já existente ao ScadaBR, sem utilizar o Java. A vantagem destes métodos seria utilizar habilidades que vc já domine em outra linguagem de programação – porém por se tratar de uma simples adaptação, vc perderá algumas das diversas características de integração dos protocolos “nativos”, como maior segurança, desempenho, salvar/exportar e instalação automática, etc.
Plano B - Alternativa 1) Método pela API - Para quem já conhece a famosa API Web-services/SOAP, este é um caminho bastante interessante pois permite integrar todas as variáveis em um simples Datasource Virtual. Modifique um protocolo já existente em qualquer linguagem, para fazê-lo rodar em um executável/script próprio, e periodicamente “ler” e “escrever” diretamente nas tags do ScadaBR, via API web-services (chamadas ReadData e WriteData).
Plano B - Alternativa 2) Uma outra forma interessante é utilizando um par HTTP Publisher + HTTP Receiver.
Pre-requisitos:
- Protocolos de comunicação (básico = entender o mecanismo request/response);
- Comunicação HTTP (básico);
- conhecimentos da linguagem de programação escolhida
Passo 1. Seleção da implementação
Utilize um protocolo já existente (procure no google [nome-do-protocolo] + open source), ou desenvolva com sua linguagem preferida a partir das especificações.
Passo 2. Fornecendo dados para o ScadaBR (HTTP get → HTTP Receiver)
Programe um ciclo de aquisição de dados no protocolo implementado (polling) onde, ao final de cada ciclo, vc faz uma requisição HTTP do tipo GET em uma URL no seguinte formato:
http://[ip-servidor-scadabr]:8080/ScadaBR/httpds?variavel=valor
No ScadaBR, adicione um datasource do tipo HTTP Receiver e o configure conforme help do datasource. Observe que após tudo configurado, seu protocolo estará “escrevendo” os valores lidos no ScadaBR.
Passo 3. Recebendo comandos do ScadaBR (HTTP Listener ← HTTP Publisher)
Modifique o ciclo de comunicação do protocolo, ou coloque uma thread em separado, onde vc faz um Listen em uma porta HTTP.
Utilize o “Publishers” do ScadaBR para que comandos escritos em um datapoint virtual configurável sejam “publicados” exatamente na porta que sua implementação do protocolo estiver escutando, sempre que houver alteração no datapoint. Observe então que o ScadaBR poderá enviar comandos para sua implementação do protocolo, que fará a comunicação adequada com o dispositivo.
Passo 4. Organizar - crie uma hierarquia ou “point links” se quiser colocar as tags de leitura (http receiver) e de escrita (http publisher) em um mesmo local.
Plano B - Alternativa 3) utilize a criatividade para integrar com SQL, TXT (Ascii File), SNMP, email, ou qualquer outro Datasource conhecido e disponível!!!
Idéias Finais
Uma última idéia que foi discutida recentemente, é que se alguém topar desenvolver um Datasource “DLL” (seguindo o plano “A” - nativo) que pudesse carregar qualquer biblioteca(DLL) via JNI/JNA, e conseguisse parametrizá-la pela interface de usuário do ScadaBR (definir a chamada de método+parâmetros na DLL para init, doPoll e para Write), seria certamente um feito interessante. Basicamente isto daria suporte a utilizar DLL´s do próprio fabricantes, para uso de protocolos proprietários no ScadaBR. Porém hoje ainda são poucos usuários que relataram esta demanda, por isso não está priorizado o suporte a DLL´s de terceiros.
Aguardamos sugestões!