Pacote SCADA ou desenvolvimento próprio｜escolha técnica do software supervisório

Quatro restrições que a escolha costuma deixar de lado

A comparação técnica facilmente vira duelo de lista de funções: alarme, tendência, relatório, protocolo. Pacote e desenvolvimento próprio fazem essas funções; a diferença está no modo de engenharia. O que de fato decide se depois se consegue manter e se o software vai junto com o equipamento na expedição são quatro restrições que contrato e acordo técnico muitas vezes deixam vagas.

• Propriedade intelectual: o projeto de configuração depende da licença de runtime do fabricante e em geral não se publica separado da plataforma; no desenvolvimento próprio, copyright e forma de entrega se escrevem no contrato — quando o fabricante de máquina expede o software com a máquina padrão, isso decide se dá para vender
• Replicação em volume: ao expedir dez ou cinquenta unidades do mesmo modelo, o pacote replica o projeto por ponto ou por licença de runtime; o desenvolvimento próprio pode transformar a lógica central num pacote configurável, licenciado por modelo, sem refazer tela
• Acoplamento fundo com o equipamento da linha: tela de supervisão sobretudo lê estado e escreve poucos setpoints; quando o algoritmo de processo, a troca de receita e o intertravamento sobem do PLC para o software supervisório, o script do pacote encontra o limite depressa
• Alterar sozinho depois: a linha muda um posto, acrescenta um instrumento, e o campo quer alterar a tela. Aí está o ponto forte do pacote; se a lógica central está em projeto criptografado ou em script difícil de manter, o engenheiro de campo não mexe e só resta contratar de novo

As quatro não têm certo ou errado: só se casam ou não com a forma de entrega. Linha de montagem, linha de embalagem e sala de supervisão de utilidades, de um lado, e o software que o fabricante expede com a máquina padrão, de outro, são o mesmo tipo de software — as restrições não são as mesmas.

Condições em que o pacote de configuração cabe melhor

O ponto forte do pacote é que a engenharia de supervisão já está pronta: driver, alarme, tendência, permissão e redundância saem da caixa, e alterar tela no campo é rápido. O uso aprofundado de pacotes de várias marcas é em si uma capacidade de entrega — continuar na plataforma que o campo já tem, em vez de forçar troca de pilha.

• A demanda é sobretudo monitorar, operar, alarme, tendência e relatório; o julgamento de processo permanece no PLC
• O campo já designou um pacote corrente, ou a sala de controle central e a supervisão de utilidades já rodam nessa plataforma
• A tela muda com frequência com a reforma da linha, e se espera que o engenheiro da planta altere sozinho, sem voltar sempre à equipe de desenvolvimento
• O projeto é supervisão de uma planta ou de uma linha, não a forma de entrega “expedir em volume junto com o equipamento”
• É preciso levantar tela de supervisão e tabela de pontos num ciclo curto; a aceitação olha se tela e alarme estão usáveis

Condições em que o desenvolvimento próprio / .NET cabe melhor

Desenvolvimento próprio não é “pacote mais avançado”: é outro entregável. Código-fonte, configuração e pacote de instalação podem pertencer, por contrato, ao fabricante da máquina ou à fábrica; o algoritmo central itera como produto. C#/.NET, VB e LabVIEW se combinam por cenário porque bancada de ensaio, máquina padrão e cliente de linha enfrentam requisitos diferentes de tempo real, interface e instrumento.

• O software vai junto com a máquina padrão na expedição; a propriedade intelectual precisa ficar no fabricante da máquina, sem se prender ao runtime de um único pacote
• O mesmo modelo se replica na entrega; a lógica central muda configuração, não código, e a licença é por modelo, não por refazer o projeto
• Algoritmo de processo, receita, intertravamento ou passo de ensaio sobem do PLC para o software supervisório, controle e gestão no mesmo lugar
• É preciso interface profunda com MES, rastreabilidade, visão ou instrumentos da bancada; o script do pacote não sustenta
• A fábrica ou o fabricante tem equipe de software e quer alterar lógica e acrescentar módulo depois, sem a restrição de licença da plataforma e de capacidade de script

Quadro: dimensão, pacote de configuração, software supervisório próprio

Escrever “cabe ou não cabe” num quadro facilita o alinhamento na reunião de escolha. A tabela abaixo não é pontuação de função: é contraste de restrições. Nas duas colunas o caminho funciona; a diferença está na forma de licença e em quem altera depois.

Caminho misto: pacote na supervisão, algoritmo central no software supervisório

No campo, o mais comum não é escolher um dos dois: é separar camadas. O pacote assume tela de supervisão, alarme, tendência e permissão, e segue com driver e redundância já verificados; algoritmo de processo, troca de receita, intertravamento e a interface com MES ou visão ficam no software supervisório ou no serviço .NET. Os dois lados trocam valor de ponto e evento por OPC UA, biblioteca intermediária ou canal de mensagem.

Essa divisão deixa a alteração de tela no lado da supervisão continua rápida, e o algoritmo e a propriedade intelectual do lado do produto ficam no código que se controla. Quando um único projeto vai de dezenas a milhares de telas, as de supervisão podem continuar no pacote; as poucas que julgam, ou o serviço de fundo, ficam no desenvolvimento próprio. A premissa é que tabela de pontos, definição de evento e modelo de permissão já estejam numa especificação de interface compartilhada; senão os dois softwares driftam cada um para o seu lado.