Evolução do ScadaBR... ou "Manifesto ScadaBR 2.0"


#1

Spoiler/Resumão

Falaremos aqui, não necessariamente nesta mesma ordem :slight_smile:

  • sobre próximos passos no ScadaBR.
  • Como atualizar o sistema para as versões modernas do Java8, Tomcat9, etc.
  • Quando teremos um novo instalador?
  • O que é o ScadaLTS e porque abraçamos parcialmente a internacionalização.
  • Como você pode ajudar?

Introdução

Atualmente o projeto ScadaBR é usado literalmente por “dezenas de milhares” de pessoas em todo o mundo. Temos muito orgulho de resolver problemas reais, todos os dias, nas mais diversas áreas que possam ser imaginadas.

Desenvolver um sistema supervisório totalmente gratuito é um grande desafio. Além da complexidade técnica em si, existem questões sociais e filosóficas - quantas pessoas têm, hoje em dia, tempo livre para disponibilizar o projeto? quem é o “dono” do software? como motivar e capacitar desenvolvedores voluntários, para agregar conhecimento nas novas versões?

Pessoalmente, como fundador do projeto e desenvolvedor de sistemas já há algumas décadas, posso ajudar a conduzir a evolução dos próximos passos, mas não tenho repostas as todas as perguntas, e nem acesso a recursos infinitos. O que podemos fazer é orientar, tentar dar ritmo, e resolver pequenos problemas, um de cada vez.

Onde queremos chegar?

A visão permanece a mesma - oferecer uma ferramenta útil, versátil, e o mais completa possível, para que pessoas comuns possam resolver problemas de monitoramento & automação no seu dia-a-dia; ao mesmo tempo que profisisonais liberais, estudantes, autônomos, e pequenas empresas, possam desempenhar profissionalmente suas funções, superando a barreira de entrada do alto custo das soluções proprietárias.

Este cenário já evoluiu (e demos uma IMENSA contribuição, com suporte de toda a comunidade), mas ainda preserva elementos de quando começamos, 15 ou 16 anos atrás.

O que precisamos para chegar lá?

Uma comunidade de software livre precisa incluir os usuários, divulgadores, profissionais capazes de treinar as próximas gerações, manter o site, escrever documentação entre outros.

Em geral, todo o trabalho hoje é voluntário. Temos um patrocinador que “banca” o site no ar, e alguns anúncios na página que ajudam com despesas miúdas - mas somos gratos particularmente a todos os usuários que publicam seus trabalhos de fim de curso, mestrados, vídeos no Youtube, respondem aos posts nos forums e contribuem em outras mídias sociais.

Sem mais delongas, porém, o recurso mais escasso hoje, onde temos dificuldade de dar uma boa vazão, é GENTE CAPAZ DE ESCREVER SOFTWARE.

Qualquer contribuição é válida - desenhar imagens para HMI, fazer debug de pequenos defeitos, corrigir traduções…

Mas precisamos também de gente capacitada para as contribuições mais pesadas. Aqui não falamos de qualquer software, e as habilidades abaixo precisam ser atendidas:

  • Desenvolvimento orientado a objetos
  • Uso correto de sistemas de controle de versão
  • Entendimento sobre sistemas operacionais
  • Desenvolvimento Web (cliente/servidor)
  • Noções de Automação e Protocolos

Mais especificamente no ScadaBR, a nossa arquitetura atual exige estes conhecimentos:

  • Desenvolvimento com Java e Tomcat
  • Conhecimento sobre a filosofia Servlets com JSP

Quais ações são mais urgentes?

A evolução para o Java 8 e Tomcat 9 são críticos, por motivos de segurança, e modificações no modelo de licenciamento da Oracle, que tornam cada vez mais difícil distribuir e encontrar o Java 6.

Quais outras ações são desejadas?

Posso citar algumas de cabeça

  • Evolução nas interfaces de usuários
  • Gráficos mais modernos com “rolar, dar zoom”
  • Aproveitamento de objetos (agrupar componentes e reutilizá-los como templates)
  • Novos protocolos
  • Correção de bugs
  • Evolução do modelo SOAP para o modelo REST
    … e uma infinidade de outras, afinal quanto mais usamos, mais idéias surgem.

A organização de idéias ou “issues” em um repositório único (lista de tarefas ou “backlog”) é altamente desejado. É possível executar este tipo de controle usando ferramentas do Sourceforge ou, mais modernamente, no Github.

O que é o projeto ScadaLTS?

Em 2017 fomos visitados por colegas europeus, principalmente o Brent de Luxemburgo e o Michal da Polônia. Fizemos grande amizade e pudemos conhecer o impacto que o ScadaBR também estava provocando lá do outro lado do Atlântico.

Seguindo no espírito do open-source, visualizou-se um “fork” ou desdobramento do projeto atual, com o fim específico de dar mais robustez e atualização ao software. A sigla LTS significa “Long Term Service” e representa a capacidade de fecharmos uma versão estável, que perdure por muitos anos, não necessariamente com muitas funcionalidades novas, mas principalmente com correções críticas e boa capacidade de dar suporte.

O ScadaLTS assim se propõe a ser um “núcleo duro” para o software, não como um concorrente para o ScadaBR, mas exatamente como uma parceria necessária na evolução.

Conseguimos com o ScadaLTS alguns objetivos interessantes - sensibilização internacional, uma mentalidade de “longa duração” com uso de versões novas do Java, bibliotecas mais atualizadas, migração para o Github, uso do Docker, entre inúmeras outras. Porém, o LTS ainda não tem uma versão fechada e 100% estável, com o mesmo conjunto de funcionalidades que tínhamos no ScadaBR. Durante o processo de evolução, muita coisa está sendo mexida, e algumas funcionalidades comuns estão “quebradas” necessitando fix (para dar um exemplo simples, a utilização de portas seriais com Modbus RTU).

Qual o futuro desejado para a Arquitetura do ScadaBR?

Para quem não conhece os detalhes técnicos, o ScadaBR pode ser descrito de maneira muito simplificada, assim:
1- O software canadense “Mango m2m” utilizado como núcleo
2- Um patch (arquivos adicionais e correções) que extendem o Mango com traduções, novos protocolos, API´s, pacotes de imagens e funcionalidades
3- Uma coleção de instaladores, especialmente para Windows com o Tomcat6 pré-instalado e pronto para usar; e outros para versões diversas de Linux.

O projeto Mango m2m em sua versão Pública ou “GPL”, tal como utilizamos no ScadaBR, foi descontinuado pelo autor original sendo repassado para uma empresa americana, a Infinite Automation. As novas versões do Mango estão (escrevo isso em 2020) “anos-luz” à frente do ScadaBR, com um software muito robusto, gratuito para pequenas instalações, e de custo relativamente baixo para uso profissional.

Mantenho contato eventual com os diretores da Infinite Automation, são excelentes profissionais e muito dispostos a ajudar, mas o enfoque mais comercial do Mango não atende aos propósitos originais do ScadaBR, de oferecer uma ferramenta 100% gratuita e baseada em comunidade. Ambos os projetos podem (e devem) coexistir de forma pacífica, cada um com seu propósito.

Com a “saída de cena” do Mango, visualizamos a necessidade de troca do núcleo do software. Precisa ser algo mantido por profissionais muito capacitados, com orientação pura de software livre (sem travas comerciais), e com visão de longo prazo. Atualmente o grupo liderado pelo Brent, Michal, Grzegorz entre outros no ScadaLTS, é o que se destaca com todos estes requisitos simultaneamente.

De maneira que um novo desenho para o “ScadaBR 2” começa a tomar esta forma:
1- O software internacional “ScadaLTS” utilizado como núcleo
2- Patches brasileiros com traduções, novos protocolos, pacotes de imagens e funcionalidades
3- Uma coleção de instaladores, especialmente para Windows com Tomcat9 pré-instalado e pronto pra usar; e outros para versões diversas de Linux.

Quanto mais as novas contribuições de software, a partir de hoje, puderem ser alimentadas diretamente no tronco principal do projeto ScadaLTS, maior a garantia de compatibilidade, apoio pelas dezenas de desenvolvedores lá envolvidos, e alinhamento com a visão de futuro do projeto.

Independente disso, com visão mais imediata e de curto prazo, há algumas ações que precisam ser tomadas para manter o ScadaBR “vivo”. Não podemos esperar uma grande reforma na arquitetura, para usufruir de benefícios práticos e de acesso imediato.

Sugestões de Roadmap

ScadaBR 1.1CE (Community Edition)
Esta versão deve preservar a arquitetura de instaladores do ScadaBR1.0CE, com a atualização crítica para Java e Tomcat.

  • Mango como núcleo
  • Build compatível em Java 8 e openJDK
  • Mudança do MySQL para o MariaDB
  • Utilização compatível com Tomcat 9
  • Patches etc; (já existentes)
  • Instaladores Windows, Linux etc; (novos ou atualizados)

ScadaBR 1.2CE (Community Edition)

  • Adição de bugfixes mínimos e novas funcionalidades, submetidos pela comunidade
  • Remoção de blibliotecas obsoletas

ScadaBR 2.0-Alfa

  • ScadaLTS (versõs de desenvolvimento) como núcleo
  • Instalador para Windows

ScadaBR 2.0-Beta

  • Correção de funcionalidades críticas “quebradas” no LTS como o Modbus RTU
  • Tradução ptBR de pelo menos 80% dos componentes
  • Novidades da comunidade

ScadaBR 2.0 CE

  • ScadaLTS em versão estável como núcleo
  • Compatibilidade com openJDK na última versão disponível no momento do build
  • Instaladores, no mínimo, para Windows 10, Ubuntu, e Docker

Por onde começar?

Estou pessoalmente bem interessado em ver o bichano rodando no Java 8, ou preferencialmente no openJDK. Infelizmente o tempo é curto e vamos gota a gota, pingando uma ou duas horinhas cada fim de semana.

Encontrei alguns guias de build no fórum e no portal.

http://www.scadabr.com.br/index.php/2017/06/06/compilacao-do-scadabr1-1/

http://www.scadabr.com.br/index.php/2017/06/06/scadabr-1-1-com-ubuntu-java8-tomcat8-e-mariadb/

O ScadaLTS roda em Java8/openJDK e é um ponto de partida para o trabalho.

O ponto crucial para sair do Java6 é a subistuição da bilbioteca Rhino, que roda os scripts e as variáveis Meta, e tem problemas de compatibilidade nos javas mais novos.

Podemos seguir a discussão neste mesmo tópico, dividindo tarefas, e compartilhando os avanços.

Onde você pode ajudar?

Estamos buscando contribuição especificamente para a ScdadBR1.1CE indicada acima.
Alguns posts no fórum e no blog já começam a nos apontar na direção correta.

Melhorias no software são muito bem-vindas, mas será difícil nos comprometer em dar “merge” nas novas contribuições antes que os itens críticos sejam sanados (Java8/openJDK, tomcat9, mariaDB).

Também é importante que novas contribuições, comecem a estar alinhadas com a stack atualizada do LTS. Lembre que nosso software já tem mais de 10 anos, o que em termos de software, já é um “ancião”.

Estamos buscando desenvolvedores de software que queiram se capacitar na direção que o “ScadaBR powered by LTS” está tomando: uso de docker, novas bibliotecas spring, uso do Vue.js, etc.

Estimulamos a criação de novos componentes gráficos, ou a conversão de pacotes de imagens gratuitas (copyleft, CC ou royalties-free) para o formato do ScadaBR

Todo tipo de idéias e contribuições são necessárias!

Considerações finais

Obrigado pela leitura!! E mãos à obra.