Novas Tendências para Sistemas SCADA.

Introdução

Neste artigo, apresentamos e discutimos o estado atual das novas tendências para sistemas SCADA.

A princípio, o panorama do mercado de automação tem se baseado, nos últimos anos, na constante evolução tecnológica e na busca da produtividade pelas empresas. Estes fatores atuam como força-motriz para um mercado que precisa investir em pesquisa e desenvolvimento para continuar a crescer. 

Por outro lado, existe uma contínua pressão pela redução de custos, tanto na parte de produtos como na de serviços. Esta pressão leva à busca da melhor relação Custo x Benefício; portanto, estudamos em quais tecnologias investir; pesquisamos quais já se consolidaram ou ainda são promessas; e então estabelecemos quais produtos uma empresa prestadora de serviços irá manter em sua cesta para se manter competitiva no seu segmento de atuação.

Em síntese, no caso específico dos sistemas de supervisão, podemos verificar alguns fatos atuais:

• O uso contínuo de ferramentas mais antigas, baseadas em plataforma Windows. Estas ferramentas, apesar de possuírem conceitos menos evoluídos, são as mais conhecidas pelo mercado.
• A criação de novas ferramentas, também para plataforma Windows, que apresentam melhores conceitos de produtividade e flexibilidade.
• A busca por novas formas de supervisão, como o uso dos servidores web em PLCs baseados em Linux ou Java.
• IHMs baseadas em Windows CE como alternativa às IHMs com hardware proprietário.
• Uso de Linux e Unix para sistemas de maior porte; isto normalmente acontece apenas em ambientes cujos usuários possuem uma cultura nesse sentido, e que estão dispostos a pagar valores maiores, devido ao menor número de cópias vendidas (como sistemas de gerenciamento de redes SNMP, sistemas de tráfego).
• Consolidação do OPC (OLE for Process Control).
• A agregação de novas funcionalidades aos sistemas SCADA como parte da estratégia de expansão, tais como análises de sistemas de produção e processos, controle de bateladas e outros.
• Total integração com a web.

Sistema Operacional

Antes de mais nada, nossa primeira conclusão a partir da análise desses fatos é a consolidação do sistema operacional Windows para os sistemas SCADA. Isto acontece porque a plataforma oferece um nível adequado de treinamento e capacitação dos profissionais; além disso, ela apresenta maior confiabilidade e capacidade de manutenção de software e hardware, mais alternativas de “produtos de prateleira” disponíveis, bem como diversos outros fatores. Todos eles são agregados a um custo compatível para a maioria das aplicações e usuários. O objetivo é manter a produtividade e eficácia das soluções, não apenas para quem compra como também para quem vende.

Igualmente, o Linux se apresenta como uma alternativa interessante; no entanto, isso se dá quando os seus fatores negativos (especialmente capacitação de profissionais e manutenção), são eliminados ou suprimidos. Um exemplo é o uso de Linux ou Java como um servidor web dentro de um PLC; neste caso, ele está restrito a uma certa plataforma. Entretanto, sempre devem ser estudados diversos pontos como a conectividade, flexibilidade e produtividade.

Arquitetura

Primeiramente, deve ser definida a estratégia de mercado; logo após, passa-se às questões sobre novas possibilidades de uso dos sistemas SCADA. É neste momento que vemos a importância da arquitetura, quando podemos incorporar esses novos usos com maior ou menor grau de flexibilidade, sem sacrificar a performance nem o tempo gasto para configuração.

Por exemplo, o uso efetivo de redes sem-fio parte do pressuposto de que a interface com o usuário através de um PocketPC com seu servidor SCADA deve ser não só rica o suficiente para fornecer informações gerenciais sobre o processo como também leve o bastante para ocupar o mínimo de banda possível da rede, além de aspectos de segurança que não podem – nem devem – ser negligenciados.

Protocolos

O uso de protocolos abertos é não apenas uma exigência de mercado como também uma questão estratégica para reduzir custos de integração, obter dados mais confiáveis e reduzir o tempo de configuração dos aplicativos. Devemos considerar não só a compatibilidade com determinado protocolo, mas também como utilizá-lo da melhor forma possível dentro do sistema SCADA. Sendo assim, questões como auto-configuração e sincronismo de bases de dados entre dispositivos e softwares devem ser considerados para se obter mais benefícios de uma arquitetura aberta.

Web

Logo após, devemos considerar como disponibilizar os dados para acesso através da web. Muitas tecnologias, principalmente as baseadas em Java ou ActiveX,  já foram usadas em diversos produtos. Uma outra possibilidade é o uso da tecnologia .NET, da Microsoft.

Antes de mais nada, é necessário que a página web que será vista pelo usuário no navegador de Internet contenha um plug-in; seu propósito é fazer com que os processos de animação gráfica e outras tarefas de segundo plano – como a notificação de mudança de valores nas variáveis de campo –, ocorram de forma espontânea, sem a solicitação do usuário. Note que os formatos de hipertexto das páginas web (HTML, ASP, PHP) não permitem este comportamento sem um plug-in.

Dessa forma, alguns softwares SCADA se propuseram a realizar conversões entre os formatos de telas e seus objetos para um outro padrão, que pudesse ser entendido pelo seu componente Java ou ActiveX no navegador, já que nem sempre é possível que o mesmo formato seja utilizado em ambos os casos. No entanto, existem outros problemas. Por exemplo, scripts baseados em VBA (Visual Basic for Applications) não podem ser executados nos navegadores disponíveis; isto faz com que as telas convertidas para a web nem sempre funcionem da forma original.

Outras soluções, como é o caso do Elipse E3, partem do princípio de que o mesmo formato de tela pode ser usado não apenas no cliente do SCADA (Windows) como também no navegador, o que evita as conversões de formato; além disso, elas também usam scripts baseados em VBScript, que podem ser executados em ambos os ambientes.

Restrições

Entretanto, o Java e o ActiveX possuem restrições. O Java requer que um runtime, capaz de interpretar o código em execução, esteja instalado na máquina-cliente. Este fator causa quedas de performance, conforme relatado por alguns clientes, justamente pelo fato de ser interpretado e não compilado. Por outro lado o ActiveX só funciona sem ressalvas se estiver dentro do ambiente Windows e com o Internet Explorer; isto pode ser problema para clientes que utilizam outros navegadores.

Quanto à comunicação, tanto o Java como o ActiveX utilizam a troca de mensagens via modelos como o Corba ou o DCOM via TCP/IP para obter as telas de seus servidores e receber as notificações de mudanças de valores. No entanto, o ActiveX possui um agravante; como é baseado na tecnologia COM (Component Object Model) e sua variante distribuída DCOM da Microsoft, ele possui diversos problemas de tráfego através de firewalls. Isto se dá porque o DCOM utiliza portas aleatórias para troca de dados; uma solução seria adotar um protocolo próprio para troca de dados na rede, baseado em TCP/IP puro, o que é bastante complexo.

.NET

A plataforma .NET propõe resolver essas questões de duas formas. Primeiramente, ela cria um ambiente de desenvolvimento único, tanto para Windows como para a web, através dos produtos Windows Forms e Web Forms®. Em segundo lugar, ela promove uma troca de dados através da web baseada em XML; este formato de texto estruturado pode passar através de qualquer firewall. Além desses dois fatores, o .NET oferece um novo mundo de possibilidades através da integração de serviços dinâmicos pela web, reutilização de componentes e criação de portais corporativos, como o SharePoint Server, o que permite que se chegue a um nível de evolução e integração nunca visto antes, mas sempre mantendo o foco na questão da produtividade e custo total de propriedade das soluções.

Além disso, o .NET permite que várias linguagens de programação diferentes sejam usadas no mesmo programa (ex: C++, VB, C#, Fortran…), o que até hoje ainda não é possível com outras tecnologias.

Figura 1 – Estrutura do .NET Framework

No entanto, alguns usuários se mostram um pouco resistentes ao uso do .NET visto que, assim como o Java, é necessário instalar um interpretador (.NET Framework) na máquina-cliente, para que o código .NET seja executado. Entretanto, a longo prazo, quando todas as novas instalações de Windows já possuírem o .NET Framework como padrão, este fato terá menor importância.

Integração de dados e OPC Unified Architecture

A gama de opções para integração de dados entre o SCADA e sistemas corporativos (ERPs, Supply Chain e outros) é cada vez mais importante. Além de manter métodos mais antigos, a busca por novas formas de modelagens e troca de dados é a parte principal da evolução desses sistemas. O acesso nativo a bancos de dados via SQL, troca de dados em TCP/IP, drivers de comunicação implementando protocolos Mestre/Escravo, objetos COM e ActiveX, dentre várias outras formas, já permitiram grandes evoluções.

É importante notar, no entanto, que nenhuma dessas metodologias possui a abrangência e importância do OPC. A especificação OPC surgiu de uma tentativa de padronização das camadas de drivers de comunicação; posteriormente, se consolidou como um grande padrão de modelagem, com as especificações de Data Access (DA), Alarmes e Eventos (AE), Históricos (HDA) e Complex Data (dados complexos), entre outros. Entretanto, devido à dependência da especificação OPC ao padrão COM/DCOM, um novo trabalho da OPC Foundation culminou na unificação dos padrões anteriores; a nova modelagem é chamada UA (Unified Architecture ou Arquitetura Unificada), mais aberta e baseada em serviços dinâmicos (Web Services) e XML.

Esta iniciativa, focada na interoperabilidade, mostra que o OPC como padrão aceito por todos permite portanto abandonar definitivamente o modelo de soluções proprietárias em busca do valor agregado que cada solução oferece. O caminho adotado nessa busca utiliza a plataforma .NET como a forma mais lógica de se obter isso; a plataforma prevê a adaptação de servidores e clientes OPC já existentes, a utilização de padrões que podem ser usados em qualquer sistema operacional e, finalmente, cria um modelo de dados que vai muito além do sistema SCADA, expandindo-o para o nível corporativo.

Considerações Finais

Após esta análise, concluímos que dificilmente uma determinada tecnologia será considerada a “vencedora” neste debate, pois sempre haverá segmentos onde uma solução específica possui benefícios que podem ser decisivos quando comparados com tecnologias concorrentes. Acreditamos, entretanto, que o .NET, como extensão natural dos padrões mais comumente encontrados hoje em dia, aparece como uma alternativa bastante promissora, especialmente quando levados em consideração todos os aspectos envolvidos nas soluções.