Elipse Knowledgebase :: Como o Elipse E3 funciona

Knowledgebase Home

Search the Knowledgebase

Browse by Category

Knowledgebase Home > Português > Elipse E3 > Outros

Como o Elipse E3 funciona

1) Introdução

Desde o lançamento do software de terceira geração Cliente/Servidor HMI/SCADA E3 pela Elipse Software Ltda. em 2001, várias aplicações foram desenvolvidas pelo mundo permitindo a construção de sistemas de automação com um novo conceito de conectividade e flexibilidade.

O E3, totalmente orientado para operação em rede e para aplicações distribuídas, oferece um novo e avançado modelo de objetos, uma poderosa interface gráfica e uma nova e exclusiva arquitetura que permite o desenvolvimento rápido de aplicações e o máximo de conectividade a vários equipamentos e outras aplicações. Também incorpora as mais recentes tecnologias de desenvolvimento de software, maximizando o desempenho e a produtividade, otimizando a qualidade de suas aplicações, bem como o próprio processo de desenvolvimento, além de minimizar custos e perdas.

Novos recursos e ferramentas de edição facilitam o desenvolvimento de aplicações e minimizam o tempo de configuração. A estrutura modular com processamento distribuído em rede do E3 reúne recursos de vídeo e dá suporte a tecnologias como XML, ActiveX e OPC.

O Elipse E3 permite a comunicação com centenas de dispositivos de controle e aquisição de dados. As informações podem ser manipuladas de diversas formas, incluindo o desenvolvimento de poderosas interfaces gráficas tanto no PC em rede local quanto via Internet, além do gerenciamento de alarmes, armazenamento em bancos de dados, troca de informações entre outros softwares e componentes e criação de relatórios.

2) Componentes principais do E3

O Elipse E3 é formado por três softwares principais, pela perspectiva do usuário:

E3 Server: Este é o Servidor de Aplicações, onde os processos do software principal são executados, incluindo comunicação em tempo real com dispositivos de controle. O servidor também é responsável pelo envio de dados e telas aos clientes conectados em qualquer ponto da rede (intranet ou internet). O servidor pode executar vários projetos ao mesmo tempo e conversar com outros servidores E3 para executar o failover de sistema (standby) ou distribuir a carga de processos entre servidores. Ele foi projetado para rodar em sistemas Windows® 2000 e XP.

E3 Viewer: Permite executar aplicações rodando no servidor em qualquer computador com o programa Viewer.exe (Windows® 98/NT/Me/2000/XP) ou com um navegador de internet. Nas duas formas não é necessário instalar a aplicação na máquina do cliente, já que todos os componentes (telas, bibliotecas e controles ActiveX) podem ser baixados e registrados automaticamente.

A licença para executar o Viewer está localizada no servidor E3. Cada servidor já tem uma licença simultânea do Viewer que pode ser aberta em qualquer lugar. O processo de logon do usuário começa com a verificação da licença no servidor e então com a autenticação do usuário. Mais licenças do Viewer podem ser adicionadas aos servidores mediante solicitação.

E3 Studio: Ferramenta única de configuração do sistema, agindo como uma plataforma universal de desenvolvimento, com um ambiente moderno e amigável, incluindo um completo editor gráfico e de scripts. Ele permite que um projeto seja editado por várias pessoas ao mesmo tempo ou que vários Studios estejam conectados ao mesmo servidor remoto com múltiplas configurações.

Figura 1 - Exemplo de arquitetura do E3

3) O conceito de Domínio

As necessidades de automação de hoje e de amanhã freqüentemente nos levam ao uso de vários computadores executando sistemas SCADA (Supervisory Control And Data Acquisition) para realizar tarefas diversas, levando em conta fatores como segurança, condições físicas e geográficas, desempenho, etc.

Para administrar essas aplicações, precisamos fazer com que elas conversem entre si, permitindo a troca de dados entre elas e a extração de dados úteis do processo. Até agora, sistemas SCADA tradicionais baseavam-se em uma estrutura comum para cumprir essa tarefa:

- Cada servidor SCADA deve ter uma cópia da aplicação (ou uma cópia parcial) configurada na base de dados local;

- Cada servidor SCADA roda somente uma base de dados configurada por vez.

Isso nos leva a alguns problemas de administração, como aplicar mudanças em todos os servidores, controlar versões de aplicações ou mesmo trabalhar com diferentes fabricantes de software.

O Elipse E3 resolve esse problema ao usar o conceito de Domínio, que inclui em um único ambiente a definição de computadores executando tarefas em tempo real (servidores) e bases de dados de projetos que devem ser executados nesses servidores, com a possibilidade de executar vários projetos em cada um. Você também pode incluir, apagar ou modificar projetos durante a execução sem afetar as outras partes do Domínio que estão rodando.

Cada projeto pode conter qualquer tipo de objeto, como gráficos (telas), Drivers de I/O, Delegação de Alarmes e Históricos, Relatórios, Fórmulas, Bases de Dados, etc. Quando dois ou mais projetos estão dentro de um Domínio, eles podem acessar as propriedades e objetos um do outro como se residissem em uma única base de dados. Isso é possível porque um objeto pode estabelecer links com outro - se ambos objetos existem e estão rodando, o link está ativo e qualquer mudança de valores é enviada assincronamente entre as partes, dependendo do tipo de link. Se um dos objetos é destruído ou parado, o link é interrompido - então a aplicação é notificada e pode indicar esse estado da forma que o usuário definir.

A estrutura de Domínio é restrita a equivalentes do servidor, como computadores servidores, projetos, usuários e senhas. A interface de usuário do cliente para operação e visualização, chamada E3 Viewer, pode conectar-se diretamente a qualquer servidor E3 com licenças suficientes do visualizador. O E3 Viewer tem três recursos especiais:

- Os projetos de aplicações residem apenas no servidor;

- Qualquer programa executável (Viewer.exe, para qualquer SO Windows®), como o Internet Explorer®*, pode ser usado como interface de operação do cliente, sem diferenças entre eles. Você também pode usar o Windows Terminal Services® para acessar a mesma interface do cliente, independente do sistema operacional;

- A interface do cliente é capaz de mudar de um servidor com falhas ou com problemas e reconectar ao próximo servidor disponível, sem ter que parar o monitoramento de processos.

* É claro que devemos ser cuidadosos com as políticas de segurança em relação a envio de comandos via internet para evitar riscos potenciais de exposição do sistema. Alguns recursos devem ser configurados na aplicação para evitar os riscos (como permissões de leitura e escrita), mas também dependem das regras da empresa onde os sistemas estão instalados.

4) A estrutura do Domínio

Em poucas palavras, um Domínio é formado fisicamente por um Servidor operando isoladamente, ou dois Servidores em uma configuração dual standby. Cada Viewer, na verdade, conecta-se ao Domínio em vez de apenas ao Servidor.

Figura 2 - Um exemplo de Super Dominio

Depois de conectados, Servidor e Cliente verificam entre si a existência de objetos de sistema registrados e atualizados na máquina cliente. Se não há objetos, o Servidor inicia o carregamento das definições dos objetos, como bibliotecas definidas pelo usuário e Controles ActiveX.

Quanto ao cliente, ele inicia baixando a primeira tela (interface gráfica), incluindo quaisquer objetos internos, e a salva em um diretório de cache. Esse processo pode levar alguns segundos, dependendo da aplicação, mas ele traz mais benefícios da próxima vez que se entra na mesma tela, já que o Viewer executa o cache de disco e de memória. Se você não fechar o Viewer, da próxima vez que abrir a mesma tela (e a tela não tenha sido reconfigurada) ela já terá sido criada em memória, portanto reduzindo o tempo de paginação. Se a tela mudou, o Viewer irá baixá-la novamente, iniciando o processo mais uma vez.

Depois de abrir uma tela, o Servidor e o Cliente somente trocam valores em tempo real e consultas a bases de dados em um esquema de mensagens TCP/IP, em modo de alta performance, quando comparado ao Terminal Services, dependendo do sistema. Isso é possível porque enquanto o E3 Viewer recebe e envia somente valores em tempo real, o Cliente do Terminal Services envia movimentos de mouse e teclado e recebe imagens de vídeo.

Entretanto, cada Domínio é capaz de conversar com outros domínios, o que de fato cria uma estrutura como a da figura acima, formando um "Super Dominio".

Um Viewer conectado a um Domínio isolado pode manipular informações residentes somente no servidor ativo, de acordo com os direitos de acesso do usuário. Entretanto, se o Domínio está inserido em um Domínio com outros irmãos, ele pode atuar como uma ponte para os outros servidores.

Assim, um ou mais Viewers conectados a um Domínio podem acessar informações residentes em outros Domínios, dependendo também dos direitos do usuário para cada Viewer. Quando ele requisita uma informação, como uma Tela ou um link para um objeto inexistente no Domínio local, o servidor local ativo age como uma porta para os viewers locais, baixando telas ou executando comunicações em tempo real entre viewers locais e servidores remotos, habilitando uma rede SCADA de larga extensão entre diferentes aplicações e sistemas.

5) Módulos de sistema do E3

A arquitetura interna do E3 é totalmente escalável, com cada tarefa principal sendo executada por um módulo em separado. Na figura abaixo temos uma visão geral dos blocos de contrução do E3.

Mais detalhadamente, o E3 Server é responsável por criar um processo em tempo de execução (E3 Runtime) que irá efetivamente executar a aplicação. Dentro desse processo encontram-se os servidores específicos do E3, com serviços usados por outros módulos.

Figura 3: Diagrama de módulos do E3

6) Bibliotecas de Símbolos e Usuários

Um dos recursos mais poderosos e interessantes do E3 é a biblioteca definida pelo usuário, que são arquivos com a extensão .LIB e que podem conter um ou mais objetos criados pelo usuário.

Esses objetos podem ser de dois tipos diferentes: XControls, que são bibliotecas gráficas executadas no Viewer, e XObjects, que são bibliotecas de dados executadas no servidor.

Os XControls são objetos gráficos do usuário com propriedades, métodos e scripts feitos com quaisquer objetos, incluindo ActiveX e outros XControls. Uma vez criados e registrados, você pode incluir o XControl em uma tela, onde define seu comportamento ou associa suas propriedades à variáveis externas. Qualquer mudança na biblioteca é automaticamente reproduzida em todas as instâncias do objeto, criando uma conexão circular de cada instância com a definição original. Como explicado anteriormente, cada cliente que abre uma tela baixa todas as definições de objetos, criando um controle de cache de telas.

Os XObjects são objetos de dados do usuário também com propriedades, métodos e scripts, junto com objetos internos relativos ao servidor (Drivers I/O, Alarmes, Históricos, etc.). O XObject é colocado em um container específico chamado DataServer onde você pode definir seu comportamento ou associá-lo a tags externos. Assim como com os XControls, qualquer mudança na definição do XObject original é automaticamente reproduzida en todas as instâncias do objeto.

Os XControls e os XObjects podem ser associados entre si para melhorar o desempenho em aplicações complexas. Você pode definir um ou mais XControls para que acessem informações de um ou mais XObjects. Os XControls só carregam as informações necessárias, deixando a base de dados completa, em tempo real, no servidor. Esse recurso permite que uma aplicação com vários itens de monitoramento tenham poucas telas, já que o XControl pode "apontar" para diferentes XObjects. Para aplicações repetitivas, o esquema de bibliotecas diminui o ciclo de desenvolvimento, pois pode incluir o driver de comunicação, tags e variáveis, alarmes, etc. Os objetos de biblioteca são também chamados de objetos ElipseX®.

Figura 4: Abordagem de XControls e XObjects

O E3 Studio também inclui uma biblioteca de símbolos vetoriais com mais de 3.000 símbolos gráficos. Esses símbolos podem ser usados em sua aplicação, diretamente nas Telas ou dentro de XControls.

7) Bases de Dados

O Elipse E3 não utiliza uma base de dados proprietária para armazenar informações - o módulo DB Server manipula qualquer base de dados comercial como o MS-SQL Server® ou Oracle®. Se você não tem a licença da base de dados, o E3 pode armazenar os dados no formato do Access® (MDB). Informações como Alarmes e Eventos, Dados Históricos e Fórmulas são armazenados em tabelas de bases de dados.

O DB Server usa os direitos do Administrador de bases de dados para criar e gerenciar tabelas, portanto você não precisa executar nenhuma manutenção da base de dados em uma ferramenta separada para manter o sistema rodando. O E3 apenas apaga dados antigos das tabelas principais ou move-os para uma tabela de backup. Após serem movidos, os dados podem ser finalmente apagados após um período de tempo definido ou mesmo retornados à tabela principal para análise posterior.

O formato das tabelas de Alarmes e Eventos é definido no módulo Servidor de Alarmes, onde você pode escolher entre os campos disponíveis, incluindo informações de Data e Hora com resolução de 1ms; as atribuições históricas e definições de fórmulas são feitas diretamente nos respectivos objetos.

8) Sincronização de bases de dados

Para uma aplicação de standby duplo (ou um subdomínio), onde as bases de dados estão localizadas nos servidores, é comum que as bases de dados criem espaços em branco de informações quando um dos servidores falha. Para evitar isso, o E3 implementa a sincronização de bases de dados entre servidores.

As informações enviadas para o servidor atual de bases de dados também sofre uma tentativa de armazenamento na base de dados de backup - se essa operação puder ser executada, então esses dados são verificados enquanto estão sendo sincronizados. Entretanto, se o processo falha, as informações não são atualizadas e sofrerão outras tentativas de armazenamento em intervalos definidos. Mesmo se ambos os servidores estão desligados, cada servidor irá transferir os registros não sincronizados para a base de dados do outro servidor quando retornar à atividade, até que completem as tarefas.

O mesmo processo é usado quando a base de dados é desconectada por qualquer motivo do DB Server. Quando isso acontece, um arquivo de armazenamento temporário é criado no computador local para manipular dados enquanto a conexão com a base de dados principal não é restabelecida.

Um problema similar acontece quando precisamos sincronizar ou concentrar bases de dados rodando em subdomínios diferentes. Nesse caso, o DB Server pode simplesmente duplicar as informações (guardando os dados em duas bases de dados ao mesmo tempo) ou mesmo executar uma sincronização de mão única com um DB Server central.

9) Servidores I/O do E3

O Elipse E3 implementa recursos especiais de gerenciamento de I/O para que aplicações de qualquer tamanho estejam habilitadas a rodar uniformemente, mesmo com centenas ou milhares de dispositivos. O conceito de driver de comunicação inclui quatro entidades:

- IOTags e IOBlocks: Estas são as variáveis extraídas de dispositivos de I/O como PLCs, controladores, placas de aquisição de dados, relés, etc. Cada IOTag é configurado para representar informações específicas e pode assumir diferentes tipos de dados, como Booleanos (verdadeiro/falso, ligado/desligado), inteiros, números reais e textos. Dependendo do equipamento e do protocolo usado, o IOTag pode ter formatos mais complexos, como estruturas de dados ou conjuntos de registros, bem como outros detalhes importantes (qualidade e data de criação, etc).

- IOConnections: Estes são os detalhes físicos da comunicação como mídia, velocidade e tipo - UDP ou TCP/IP, serial, modem, RAS, etc. Cada dispositivo de comunicação deve estar associado a um IOConnection, sendo possível a vários dispositivos de comunicação compartilhar a mesma conexão (como uma rede multidrop RS-485).

- IOServers: programas executáveis que manipulam comunicações. Você pode definir que um IOServer irá manipular um número específico de conexões, assim o E3 irá criar mais IOServers dinamicamente para gerenciar mais conexões e dispositivos.

Figura 5: Configuração típica de drivers

10) Cliente e servidor OPC

O Elipse E3 pode agir tanto como um cliente quanto como um servidor OPC para maior conectividade, incluindo troca de informações com outros pacotes SCADA.

11) Gerenciamento de Alarmes

O E3 define três entidades principais para o Gerenciamento de Alarmes: AlarmConfig, onde você pode inserir Áreas de forma hierárquica; por sua vez, pode manipular AlarmSources que definem explicitamente o tipo de verificação (Analógica, Digital, Taxa de Mudança, Banda Morta) e fonte (IOTag, variável interna, etc.).

Durante a execução as mensagens de alarme são enviadas para o AlarmServer, que gerencia o AlarmHub, controlando a entrada/saída de mensagens para outros servidores e clientes e o reconhecimento de usuários.

As mensagens podem ser visualizadas e reconhecidas pelo usuário com objetos, habilitando a filtragem de mensagens, controle de cores, pisca-pisca e ordenação.

12) Relatórios avançados

O E3 inclui ferramentas de relatórios de alto nível que lhe permitem criar virtualmente qualquer tipo de relatório de histórico e em tempo real. Com a ferramente E3 Query você pode criar e gerenciar consultas SQL para extrair as informações que quiser das bases de dados, com filtros, ordenações, visualizações, etc., permitindo também editar manualmente as consultas SQL.

Com o designer gráfico de relatórios você pode definir a aparência do relatório, com cabeçalhos e rodapés, grupos e seções de detalhes, incluindo cálculos especiais como somas, médias, desvios-padrão, etc. Dentro de cada seção você pode ter objetos como códigos de barra, desenhos, imagens, etiquetas, campos de dados (de consultas SQL), scripts (VBScript) e Tendências/Gráficos.

A saída do relatório pode ser pré-visualizada na tela, enviada diretamente para a impressora ou exportada para os formatos Acrobat® PDF, Microsoft Excel®, RTF ou HTML.

13) Conhecimento especializado e presença mundial

A Elipse Software traz conhecimento especializado para várias áreas de aplicação, tais como Química, Águas e Esgotos, Energia Elétrica(Geração, Transmissão e Distribuição), Energia (Medição, Proteção, Gerenciamento), Processo e Produção, com filiais e distribuidores em vários países, como Estados Unidos, Alemanha, Índia, Taiwan e Brasil.