Elipse Knowledgebase

• O uso contínuo de ferramentas mais antigas, baseadas em plataforma Windows que, 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, somente 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 licenças 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

A primeira conclusão a partir da análise desses fatos é a consolidação do sistema operacional Windows para os sistemas SCADA. As razões são o fato desta plataforma oferecer um nível adequado de treinamento e capacitação dos profissionais, confiabilidade, capacidade de manutenção de software e hardware, mais alternativas de "produtos de prateleira" disponíveis e diversos outros fatores, agregados a um custo compatível para a maioria das aplicações e usuários. Tenha-se sempre em mente que o objetivo é manter a produtividade e eficácia das soluções, tanto para quem compra como para quem vende.

Aliado a isto, vemos o Linux como uma alternativa interessante quando os seus fatores negativos, especialmente no que tange à capacitação dos profissionais e à manutenção, são eliminados ou suprimidos. O uso do Linux ou de um Java atuando como um servidor web dentro de um PLC é um exemplo, pois está restrito a uma certa plataforma. Entretanto, sempre devem ser estudados diversos pontos como a conectividade, flexibilidade e produtividade.


Arquitetura

Definida esta estratégia de mercado, e passando às questões sobre novas possibilidades de uso dos sistemas SCADA, vemos que a arquitetura passa a ser importante quando podemos incorporar esses novos usos com maior ou menor grau de flexibilidade, sem sacrificar a performance nem o tempo gasto para configuração.

O uso efetivo de redes sem-fio, por exemplo, parte do pressuposto de que a interface com o usuário através de um PocketPC com seu servidor SCADA deve ser rica o suficiente para fornecer informações gerenciais sobre o processo e, ao mesmo tempo, 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, além de uma exigência de mercado, se tornou uma questão estratégica para a redução de custos de integração, obtenção de dados mais confiáveis e também de redução no tempo de configuração dos aplicativos. Isso porque devemos considerar não só a possibilidade de ser compatível com determinado protocolo, mas de 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

A próxima questão sobre arquitetura que vem à tona é como disponibilizar os dados para acesso através da web. Muitas tecnologias já foram usadas em diversos produtos, sendo as principais baseadas em Java e em objetos ActiveX. A mais nova possibilidade é o uso da tecnologia .NET, da Microsoft.

Via de regra, é necessário que a página web que será vista pelos usuários no navegador de Internet contenha um componente de software conhecido como plug-in, para 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, visto que os formatos de hipertexto das páginas web, como HTML, ASP e PHP, não permitem este comportamento sem o uso de tais componentes.

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, visto que nem sempre é possível que o mesmo formato seja utilizado em ambos os casos. Existem, porém, outros problemas, como o fato de que scripts baseados em VBA (Visual Basic for Applications) não podem ser executados nos navegadores disponíveis, o que faz com que as telas convertidas para a web nem sempre funcionem da forma original.

Outras soluções, como é o caso do E3, da Elipse, partiram do princípio de que o mesmo formato de tela pode ser usado tanto no cliente do SCADA, em Windows, como no navegador – o que evita as conversões de formato –, além de usar scripts baseados em VBScript que podem ser executados em ambos os ambientes.

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. Já o ActiveX só funciona, sem ressalvas, dentro do ambiente Windows e para o Internet Explorer, o que pode ser problema para clientes que utilizam outros navegadores.

Quanto à parte de 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. O ActiveX, porém, possui um agravante pois, como é baseado na tecnologia COM (Component Object Model) e sua variante distribuída DCOM da Microsoft, possui diversos problemas de tráfego através de firewalls, uma vez que o DCOM utiliza portas aleatórias para troca de dados. Uma solução para isso 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: criando um ambiente de desenvolvimento único, tanto para Windows como para a web, através dos produtos Windows Forms e Web Forms®; e uma troca de dados através da web baseada em XML, que é um formato de texto estruturado que 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, permitindo que se chegue a um nível de evolução e integração nunca visto antes, 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 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, pensando 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.