segunda-feira, 10 de dezembro de 2012

Modbus – Um Protocolo e Diferentes Implementações

Alguns padrões de comunicação simplesmente aparecem e são adotados pelo mercado!

Não é porque eles são empurrados, de cima para baixo, por um grupo de fornecedores grandes ou por uma organização de padronização. Padrões como o Modbus aparecem e são adotados pelo mercado porque eles são bons, simples de implementar e são, como consequência, adotados por inúmeros fabricantes. Devido a isso, o Modbus tornou-se um padrão amplamente aceito nos diversos segmentos do mercado de automação.

Em 1979, a Gould-Modicon lançou para seus CLPs a rede de comunicação Modbus. Ela tinha como base o protocolo de comunicação Modbus serial. Este protocolo era apresentado em duas versões:
  • Modbus serial RTU.
  • e, Modbus serial ASCII.
A rede de comunicação Modbus operava sobre os padrões RS-485 (para redes multiestação) e RS-232 (para conexões entre duas estações).

A Gould-Modicon, após lançar a rede Modbus, disponibilizou publicamente as especificações do protocolo e da rede. De forma que qualquer empresa que quisesse implantar este padrão em seus equipamentos poderia fazê-lo sem ter que pagar qualquer direito de uso à Gould-Modicon.

No início dos anos 80, a Gould-Modicon lançou para seus CLPs a uma evolução da rede de comunicação Modbus, chamada Modbus Plus.

No caso da rede Modbus Plus, a Gould-Modicon não disponibilizou ao público as especificações de protocolo e da rede, transformando-a em uma rede proprietária.
A rede Modbus Plus foi descontinuada ao final dos anos 90 e, na prática, não é mais encontrada.

Como a rede ethernet se popularizou na automação industrial a partir de meados dos anos 90, a comunidade de usuários passou a usar o protocolo Modbus serial neste tipo de rede, usando um método chamado de encapsulamento.

E, finalmente em 1999, foi lançada a especificação do protocolo Modbus para redes ethernet. Esta nova versão do protocolo definiu o uso do TCP/IP para o transporte das mensagens e foi chamada de Modbus TCP.

No início dos anos 2000 a Schneider Electric, sucessora da Gould-Modicon e outros, deu suporte à criação da "The Modbus Organization". Esta organização, sem fins lucrativos, é mantida pela comunidade de usuários do protocolo com objetivo de manter e gerenciar a necessidade de evolução das especificações do protocolo, incentivar seu uso e oferecer informações necessárias para a sua correta implementação (http://www.modbus.org). Esta organização criou e incentiva um programa de testes para certificação de produtos que implementam o protocolo.

Esta iniciativa permite aos usuários evitar a compra de produtos que incorporem drivers Modbus implementados com interpretações particulares das especificações – muito comuns no passado.

As duas maiores dificuldades de uso do protocolo Modbus estão relacionadas a:
  • documentação sobre a interface de comunicação, sua parametrização;
  • mapa de memória do dispositivo;
  • e, implementações com interpretação particularizada das especificações.
Por exemplo, para implantar um sistema composto de um supervisório e alguns dispositivos Modbus (medidores de energia, pequenos CLPs ou outros), são necessários:
  • configurar os parâmetros de rede na interface de comunicação do computador e dos dispositivos;
  • e, ter o mapa de memória do dispositivo listando cada variável do dispositivo com seu endereço Modbus equivalente.
As informações necessárias para executar estas tarefas deveriam fazer parte da documentação (ou de anexos) de cada dispositivo. Mas, na prática, a documentação não apresenta as informações de forma clara e padronizada e muita vezes tem que ser solicitadas ao suporte técnico do fabricante do dispositivo (não vem junto com o dispositivo).

Outro fator de confusão na implementação deste tipo de sistema são as implementações do protocolo com interpretação particularizada das especificações. O protocolo Modbus foi criado faz 30 anos, e, muitos recursos e funcionalidades comuns nos equipamentos de hoje em dia não existiam nos equipamentos naquela época. Com isto, recursos tais como: números muito grandes, números de ponto flutuante, formas de endereçamento e alocação de memória para os diferentes tipos de dados, entre outras, não foram considerados nas definições do protocolo. Com isto as empresas criaram suas próprias definições, a partir de práticas existentes ou fazendo definições particulares.

Por exemplo, existem alguns formatos para os números de ponto flutuante: meia precisão, precisão simples ou dupla, com sinal ou sem sinal.

Que forma armazenar estes números na memória dos dispositivos? Os fabricantes dos dispositivos, uma vez que a especificação do protocolo não faz qualquer definição acerca, podiam optar por algum padrão existente ou criar seu próprio padrão de armazenamento.

Esta falta de definição na especificação do protocolo cria uma dificuldade para o usuário, caso o fabricante do dispositivo não informe de forma clara na documentação qual o formato usado para armazenar os números de ponto flutuante na memória do dispositivo.

Como a questão do ponto flutuante, existem outros desvios ou implementações particularizadas que causam confusão na implantação de sistemas com o protocolo Modbus, tais como:
  • endereçamento das Estações Escravo Modbus (com mais de um byte);
  • modo Broadcast;
  • endereço dos Registros (base 0 x base 1);
  • endereço dos Bits (base 0 x base 1);
  • ordem de transmissão dos bytes nos registros;
  • ordem de transmissão para valores que usam mais de um registro (números de 32 ou 64 bits - inteiros ou ponto flutuante).
Vamos examinar a questão da ordem de transmissão dos bytes nos registros.

O protocolo Modbus especifica que para transmitir um registro (dois bytes) o dispositivo deve transmitir primeiro o byte de ordem superior e depois o byte de ordem inferior. Ou seja, para transmitir o valor 0x35A2 ele deve transmitir 35 no primeiro byte e A2 no segundo byte, desta forma o dispositivo que recebe o valor vai decodificar 0x35A2 e apresentar o valor decimal 13.730.

Porém alguns fabricantes não respeitam esta definição do protocolo e ao invés de transmitir 35 no primeiro byte e A2 no segundo byte, eles fazem a transmissão invertida. Primeiro é transmitido o A2 e depois é transmitido o 35, desta forma o dispositivo que recebe a mensagem vai decodificar 0xA235 e apresentar o valor decimal 41.525, que não corresponde ao valor na memória do dispositivo original.

Alguns drivers, no editor de configuração, têm uma opção que permite desfazer esta inversão. Neste caso é só habilitar esta opção e o driver faz a inversão de bytes a cada dois bytes de dados recebidos.

Se o seu driver não fizer esta inversão, você vai ter que escrever uma rotina de programa para fazê-la.

Este tipo de inversão é mais comum do que se imagina, portanto quando você estiver recebendo um valor diferente do valor de origem faça a conversão do valor na origem e no destino para o formato hexadecimal e verifique se você não está tendo uma inversão de bytes na transmissão.

segunda-feira, 3 de dezembro de 2012

Apresentando dados dinâmicos na web

Sem a necessidade de um sistema SCADA


Os gerentes de empresa sabem que as informações importantes sobre seus processos produtivos estão nos sistemas que controlam a produção. Sendo assim, cada vez mais é importante disponibilizar os dados dinâmicos de chão de fábrica para toda a empresa para que seja possível monitorar, em tempo real, o desempenho e a programação da produção. Quando nós  falamos de dados dinâmicos, nós estamos nos referindo a dados cujo valor altera constantemente. Dados como: dados de processo, métricas KPI de negócios e outros.

E a melhor forma de disponibilizar estes dados é através de páginas de internet. Assim, a partir de qualquer computador com acesso a Internet, é possível visualizar as informações usando apenas um navegador. É interessante poder apresentar os dados em diferentes formatos como: cartas de tendência, tabelas, controles deslizantes, medidores, barras de progresso e outros. Sempre que os dados mudarem de valor os elementos na tela devem atualizados automaticamente, sem a necessidade de fazer o “refresh” da página.

Porém, apresentar dados que mudam constantemente desta forma em uma página de internet sempre foi um desafio para desenvolvedores e para usuários.

Uma solução freqüente é usar cliente web dos softwares SCADA. Porém a tecnologia de internet avança rapidamente, e os principais fornecedores SCADA não. Atualmente todos os grandes fornecedores de software SCADA estão usando tecnologias de internet antigas, tais como ActiveX, Java e ASP. Além disso, em todos os softwares SCADA você precisa pagar pelo número de pontos ou pelo número de conexões de cliente web que você precisa.

Figura 1. Arquitetura de visualização de dados dinâmicos usando SCADA Web Server 


A tecnologia de internet mais recente disponível no mercado é o Silverlight da Microsoft, que permite a criação de telas atraentes e com atualização rápida para a web, e com os mais altos padrões de segurança disponíveis em um navegador. Um software que permite apresentar dados de processo na web de forma dinâmica, sem necessidade de um sistema SCADA e que utiliza a tecnologia Silverlight, é o DataHub WebView da Cogent Real-Time Systems.

O DataHub WebView é um aplicativo do tipo “cloud”, auto hospedado, projetado para a apresentação de telas gráficas dinâmicas (animadas) através da web. Baseado na última tecnologia da Microsoft, o Silverlight 4.0, e no núcleo do DataHub da Cogent, este aplicativo introduz novas formas de apresentar dados de processo em qualquer sistema interligado por rede ou Internet usando browsers de internet. Simples de instalar, ele permite criar em pouco tempo seu sistema baseado em uma “cloud” particular. Você pode controlar quem acessa, quais dados podem ser acessados e quem tem direitos para criar novas telas.


Figura 2. Arquitetura de visualização de dados dinâmicos usando DataHub WebView da Cogent 


O DataHub WebView não cobra por número de ponto nem por número de conexões de cliente. Ou seja, por um custo único você pode criar quantas páginas quiser, com quantos pontos forem necessários, que podem ser acessados por um número ilimitado de clientes.


Figura 3. (a) Tela do DataHub WebView apresentando dados dinâmicos na web e (b) Tela do DataHub WebView em modo de edição de tela pela web


Clique aqui para obter mais informações sobre o DataHub WebView.

quinta-feira, 22 de novembro de 2012

IEC 61850 em Sistemas de Automação

IEC 61850 é um conjunto de normas que define e garante a interoperabilidade entre equipamentos usados em Sistemas de Automação de Subestações (SAS). Este conceito inicial foi expandido, e hoje abrange outros sistemas tais como centrais hidrelétricas, centrais de geração eólica e sistemas de distribuição inteligente (smart grids).
 
O uso do padrão IEC 61850 em sistemas supervisórios permite monitorar equipamentos a partir de leitura de dados de relés e RTUs e enviar comandos para operar seccionadoras e disjuntores. 
 
O primeiro grande benefício do uso do IEC 61850 é a funcionalidade de auto-discovery. Esta funcionalidade permite que um driver de comunicação cliente IEC 61850, instalado junto com um supervisório, interrogue um driver servidor IEC 61850, em um equipamento, solicitando a lista de pontos existentes no equipamento e recebe como resposta a lista de pontos do equipamento. Esta função reduz em muito o tempo de configuração de pontos dos equipamentos no supervisório.
 
O segundo benefício é a padronização do mapeamento dos dados (incluindo nomes) nos equipamentos, imposto pelo IEC 61850. Este mapeamento define o nome do ponto e sua estrutura, de forma que a corrente média da fase A em qualquer equipamento que implementa o IEC 61850 será um ponto flutuante com o seguinte nome:
 
MX$A1$phsA$instCVal$Mag$f R Float
 
No nome acima ainda serão apostos dois prefixos que correspondem ao nome/endereço do relé e o nó lógico em que está alocada esta variável. A padronização de nomes facilita sobre maneira a vida do configurador do supervisório, pois ele não precisa usar uma tabela de endereçamento para identificar os pontos.
 
O terceiro benefício consiste na padronização dos métodos de comunicação. Para o supervisório ler dados / receber dados do equipamento o protocolo prevê o método de pooling (varredura periódica), ou seja, o supervisório estabelece uma taxa de varredura e dispara leituras ao equipamento nesta taxa. Porém, o mais usual em sistemas elétricos é o equipamento enviar dados para o supervisório somente quando os dados sofrem alteração. Para esta modalidade, o protocolo previu dois métodos:
 
Buffered Reports: o equipamento envia os dados e o supervisório envia uma confirmação de que os dados foram recebidos e que estão íntegros. Enquanto o equipamento não recebe esta confirmação, ele continua realizando retentativas de envio. Deve ser usado em aplicações do tipo SOE (Sequence Of Events).
 
Unbuffered Reports: o equipamento envia os dados que sofreram alteração, porem não espera por confirmação do supervisório. Muito bom para ler as variáveis físicas do sistema elétrico (tensão, corrente, potência, etc.).

O protocolo prevê também o envio de comandos (escrita do supervisório para o equipamento) nas modalidades tradicionais: comando direto (Select Before Operate), comando por pulso ou comando por memória (Let). O supervisório também pode enviar valores de set-point para o equipamento.
 
Acrescido de uma interface OPC, o driver cliente IEC 61850 permite monitorar dados de sistemas de energia em qualquer aplicação de supervisório / SCADA (Supervisory Control And Data Acquisition) ou DCS (Distributed Control System) provido de uma interface Cliente OPC. Assim, abre a possibilidade de monitorar informações vindas dos sistemas elétricos no mesmo software-aplicativo que monitora a área de produção de uma planta industrial.
 
 
Exemplo de configuração de um driver IEC 61850 com interface OPC
 

Redundância de Servidores OPC


Maior Disponibilidade dos Dados do Chão de Fábrica

A tecnologia OPC é um dos desenvolvimentos mais bem-sucedidos na área de software para automação industrial. Hoje em dia praticamente todas as aplicações (seja supervisório, historiador, aplicativo de MES, gerenciador de alarmes) oferecem interface OPC DA. A tecnologia OPC DA provou ser confiável em praticamente todas as situações que requerem acesso a dados de dispositivos e sistemas. Com o sucesso da tecnologia OPC, não é de se admirar que tantos aplicativos e soluções passassem a depender desta tecnologia para a disponibilidade dos dados. 
 
As aplicações não podem perder a conexão com suas fontes de dados. Falhas de comunicação causam perda de produtividade, geração de rejeitos, redução da qualidade e até risco de vida.
 
Há muitos fatores que podem afetar a qualidade e a confiabilidade dos dados. Pode ocorrer falha na conexão entre a aplicação cliente e o servidor OPC, seja por um problema no computador onde roda o servidor OPC, uma falha na rede, ou até mesmo uma falha humana que cause o desligamento do servidor OPC. Em outros casos, a conexão entre o servidor e o cliente OPC pode estar funcionando perfeitamente, mas pode haver falha na conexão entre o servidor OPC e os dispositivos. Nestes casos, o servidor OPC está funcionando corretamente, mas não é capaz de fornecer os dados.
 
O diagrama abaixo apresenta uma arquitetura típica. Todas as aplicações cliente OPC estão acessando um único servidor OPC e este servidor OPC é o único responsável pela coleta de dados dos dispositivos. Se por qualquer motivo, falhar a conexão com o servidor OPC ou falhar a conexão com os dispositivos, as aplicações ficaram sem acesso aos dados. Para aumentar a confiabilidade do sistema, é necessário remover esses pontos únicos de falha.
 
 
Para eliminar o ponto único de falha, deve-se usar mais de um servidor OPC, ou seja, um par de servidores OPC redundantes. O problema é que isto requer que a aplicação cliente OPC seja capaz de gerenciar esta redundância.
 
Algumas aplicações tem a capacidade nativa de gerenciar a redundância de servidores OPC ou tem esta funcionalidade como opcional. Para estas aplicações nenhum software adicional é necessário, a menos que a solução não atenda algum critério técnico do usuário ou por razões de custo. Se o aplicativo cliente OPC não tiver esta capacidade é preciso então buscar outra solução.
 
Alguns usuários decidem desenvolver rotinas em seus sistemas para implementar o gerenciamento da redundância. Apesar de parecer uma boa solução, o desenvolvimento de rotinas pode apresentar problemas. Elas precisam ser criteriosamente testadas para garantir o funcionamento correto em situações críticas. Qualquer modificação no sistema implica em realizar todos os testes novamente. Além disso, é necessário treinar a equipe para suportar e manter estas rotinas. Em alguns casos, as rotinas não realizam o chaveamento de forma confiável ou podem causar falsos chaveamentos, por não serem otimizadas exclusivamente com objetivo de gerenciar a conexão aos servidores OPC redundantes.
 
Uma alternativa às rotinas é o uso de um software de gerenciamento de redundância específico que é instalado junto ao cliente OPC. Estes softwares são tipicamente otimizados para gerenciar a conexão com os servidores OPC redundantes, garantindo o desempenho do sistema.
 
Normalmente estes gerenciadores de redundância permitem a configuração de:
  • Critério que determina o chaveamento para o servidor secundário;
  • Servidor preferencial;
  • Critério para restaurar a comunicação com servidor primário;
  • Monitoramento da conexão;
  • Armazenamento dos eventos de chaveamento e;
  • Envio de notificação quando ocorre o chaveamento.

O software de gerenciamento da redundância deve ser capaz de ser inserido no sistema sem a necessidade de mudanças na configuração do cliente OPC ou do servidor OPC. O gerenciador de redundância deve “aparecer” como servidor OPC para o seu cliente OPC. Para a aplicação cliente OPC deve ser transparente se a conexão está sendo feita ao servidor OPC primário ou ao secundário. A aplicação cliente OPC não deve perceber que houve o chaveamento entre os servidores OPC, mas é importante que esteja ciente de que o evento ocorreu para sinalizá-lo, de forma que sejam tomadas medidas corretivas necessárias.
 
 
Em resumo, o software de gerenciamento de redundância aumenta a confiabilidade e a disponibilidade de dados OPC, permitindo que múltiplos servidores OPC sejam configurados em pares redundantes. Assim como em qualquer item de um bom projeto ele deve ser considerado o quanto antes possível, na fase inicial de projeto.

OPC Tunneling: uma alternativa ao DCOM no chão de fábrica

A facilidade de comissionamento e a simplicidade para estabelecer a comunicação Cliente / Servidor OPC, quando instalados em um mesmo computador, são as razões principais para a popularidade e a difusão do uso da Tecnologia OPC. O mesmo não pode ser dito quando Cliente e Servidor OPC são instalados remotamente, em computadores interligados por rede. Por exemplo, um sistema supervisório com driver Cliente OPC em um computador e um driver de comunicação com interface Servidor OPC em outro computador, interligados por rede.
 
O uso da tecnologia COM/DCOM é a responsável pelo sucesso da Tecnologia OPC, mas também é a fonte das dificuldades quando se trata de uma conexão remota. A Segurança DCOM controla as conexões remotas feitas aos programas instalados em um computador. A Segurança DCOM evita que um programa remoto controle um programa em seu computador, exatamente o comportamento de um vírus ou malware. De forma que, para estabelecer a comunicação entre o Cliente e o Servidor OPC remotos, é necessário fazer ajustes na Segurança DCOM para definir permissões de acesso e outras permissões necessárias. Este ajuste da Segurança DCOM, normalmente, requer um especialista com conhecimento nesta área.
 
Para responder a essa dificuldade, os desenvolvedores criaram uma tecnologia chamada “OPC Tunneling”, baseado em TCP/IP, e que pode ser usada para substituir o DCOM na comunicação remota entre o Cliente e o Servidor OPC. Com esta tecnologia, o Cliente OPC em um computador se conecta ao componente túnel em sua máquina e o Servidor OPC em outro computador se conecta ao componente túnel em sua máquina. Os componentes do túnel comunicam entre si, através da rede, transferindo os dados OPC entre os computadores e consequentemente entre o Cliente e o Servidor OPC remotos.
 
 
A Tecnologia OPC Tunnelling é usada apenas no transporte dos dados entre os computadores remotos. A atualização de dados entre os componentes remotos do túnel é feita por espelhamento, ou seja, se ocorre a mudança de valor de uma variável em uma ponta o novo valor é automaticamente transferido para a outra ponta (e vice versa). Não se usa mecanismo de transferência periódica, o que torna a comunicação OPC Tunnelling muito eficiente. Normalmente a comunicação OPC Tunnelling oferece as opções de transferência de dados com ou sem criptografia, aumentando a segurança caso esta transferência seja feita entre computadores situados em locais diferentes.
 
A Tecnologia OPC Tunnelling pode ser usada através de firewall ou pela internet, estendendo o alcance da Tecnologia OPC que não opera nestes ambientes. Configurar uma comunicação OPC Tunnelling é muito simples, é necessário apenas informar a porta e o endereço IP do componente túnel remoto (nos dois lados).
 
O uso desta tecnologia também transforma a comunicação Cliente / Servidor OPC remota em algo simples de configurar e fácil de comissionar. Existem, no mercado, diversos produtos que implementam a Tecnologia OPC Tunnelling.

Servidor de Comunicação OPC: otimizando a rede de automação

Ao longo dos anos, os desenvolvedores de softwares de automação desenvolveram drivers de comunicação dedicados para cada dispositivo de campo e seus diferentes protocolos de comunicação. O desenvolvimento da tecnologia OPC padronizou a interface de comunicação e permitiu que mais de um aplicativo de software com interface Cliente OPC pudesse buscar dados de um mesmo Servidor OPC. Abriu-se a oportunidade para se ter o conceito de um Servidor de Comunicação OPC, reduzindo drasticamente o número de interfaces entre os diversos sistemas de automação com os inúmeros dispositivos de campo.


Figura 1: Acesso aos dados diretamente no CLP



Figura 2: Acesso aos dados usando um Servidor de Comunicação OPC

O uso de um Servidor de Comunicação OPC centralizado reduz o número de interfaces e algumas de suas vantagens são:
  • Otimiza o tempo de resposta dos CLPs reduzindo a quantidade de mensagens solicitadas, uma vez que o mesmo dado necessário no sistema supervisório e no sistema historiador é consultado uma única vez.
  • Diminui o custo de novos projetos de automação e de gerenciamento da produção, não sendo necessário adquirir um driver de comunicação para cada novo sistema.
  • Facilita a manutenção dos sistemas de automação, havendo apenas um único driver de comunicação para gerenciar.
  • Diminui custo de projetos de ampliações, permitindo aproveitar controladores existentes.
  • Reduz o risco de paradas na produção devido a falhas nos controladores.
Com a nova topologia, o Aplicativo Cliente (um supervisório com driver cliente OPC) roda em um computador e os drivers OPC do Servidor de Comunicação OPC rodam em outro computador. Desta forma é necessário implementar uma comunicação remota cliente / servidor OPC. Como a Tecnologia OPC depende do DCOM para a troca de dados em rede e o ajuste do DCOM para comunicação entre máquinas remotas nem sempre é simples e direto, o uso da tecnologia OPC Tunneling é uma boa alternativa. A Tecnologia OPC Tunneling torna simples a configuração da troca de dados entre sistemas remotos, aumentando a segurança e confiabilidade.

Com o uso de um Servidor de Comunicação OPC todos os dados dependem agora deste sistema. Para aumentar a disponibilidade do sistema, em sistemas de missão crítica, é interessante prever a Redundância de Servidores de Comunicação.

 

domingo, 9 de setembro de 2012

KEPServerEX, Servidor de Comunicação


O KEPServerEx é um programa de computador criado, desenvolvido e mantido pela Kepware, a proprietária de seus direitos.
 
Usando o KEPServerEx, um programa de computador pode se comunicar - trocar dados - com equipamentos de controle, monitoração e coleta de dados usados na automação industrial, predial e de sistemas de energia.
Programas de computador como:
  • Sistemas Supervisórios,
  • Historiadores,
  • MES,
  • Sistemas de Relatório,
  • Sistemas de Gerenciamento de Empresas (ERP),
  • Sistemas de Bancos de Dados
e outros podem usar o KEPServerEx para trocar dados com equipamentos.

O KEPServerEx troca dados com diversos tipos de equipamentos como:
  • Controladores Programáveis (CLPs),
  • Controladores de Malha,
  • Sistemas Digitais de Controle Distribuido (DCSs),
  • Registradores,
  • Indicadores Digitais,
  • Balanças,
  • Leitores de Código de Barra,
  • Relês de Proteção,
  • Sistemas para Telemediçao e Controle Remoto (RTUs)
e inúmeros outros.

Resumindo, diversos programas de computador usam o KEPServerEx, que também é um programa de computador, para trocar dados com equipamentos.

O KEPServerEx é um produto sensacional porque ele permite que vários programas de computador (independente do desenvolvedor - a firma que criou e desenvolveu programa) troquem dados com inúmeros equipamentos  (independente do fabricante - a firma que criou e fabrica o equipamento). Com isso ele proporciona a interoperabilidade - capacidade de conectar e trocar dados - entre programas e equipamentos de desenvolvedores / fabricantes diferentes. A interoperabilidade permite aos usuários escolher os programas e os equipamentos de sua preferência para especificar e desenvolver seus sistemas de controle.

O KEPServerEx também é um produto sensacional porque a forma de configurar a troca de dados com os equipamentos e o mecanismo de conexão com os programas são padronizados. Para o usuário, esta padronização é muito interessante pois facilita a aprendizagem no uso (configuração) do produto.

Configurar a troca de dados entre um programa e um equipamente é uma atividade com muitos detalhes, ou seja, a parametrização da comunicação exige que sejam definidos vários parametros. E basta um parametro errado para que nada funcione. Neste aspecto, o KEPServerEx também é um produto sensacional porque ele inclui assistentes de configuração para orientar e guiar o usuário na hora da configuração do produto. O assistente de configuração guia o usuário em todos os passos na parametrização da comunicação, evitando que sejam feitos erros durante este procedimento.

Para especificar o driver de comunicação correto, a ser usado pelo KEPServerEx, na troca de dados com um determinado equipamento deve ser levado em conta diversos detalhes da comunicação. Assim como não existe uma resposta genérica ou padronizada para questões de comunicação cada pergunta ou dúvida do cliente precisa ser esclarecida, estudada e vai gerar uma resposta específica.

Definir drivers de comunicação ou responder a questões sobre comunicação é uma tarefa complexa pela necessidade de conhecimento e pela diversidade do assunto, este blog vai ajudá-lo nesta tarefa.

Nas próximas postagens vamos falar sobre o KEPServerEx discutir suas características.

A Estrutura do KEPServerEX


Vimos que o KEPServerEx é um programa de computador, com a função de Servidor de Comunicação. Vimos também que o KEPServerEx é usado como um "mecanismo" que executa a troca de dados entre programas de computador e equipamentos.
  • Qual é a estrutura do KEPServerEx?
 Nesta postagem vamos responder esta pergunta.

Para maiores informações sobre a estrutura do KEPServerEx visite sua página no site da Kepware.

KEPServerEx é composto por dois componentes de software:
  • as interfaces de comunicação - para comunicação entre o KEPServerEx e os programas de computador;
  • os drivers de comunicação - para comunicação entre o KEPServerEx e os equipamentos.
componente de software
É uma rotina de software que executa uma função específica. No caso do KEPServerEx as interfaces de comunicação fazem a comunicação com outros programas e os drivers de comunicação fazem a comunicação com os equipamentos.
Resumindo, o KEPServerEx é programa de computador que inclui pelo menos dois componentes.
As intefaces de comunicação estão sempre incluídas no produto.
Os drivers de comunicação precisam ser especificados.

Os drivers de comunicação são módulos independentes e eles são especificados em função do equipamento com o qual o KEPServerEx vai se comunicar.
 
Resumindo para especificar o KEPServerEx você precisa definir ao menos um driver de comunicação.

Por isso quando fazemos uma cotação ou fazemos um pedido à Kepware especificamos o produto da seguinte forma:
KEPServerEx com suite de suite de drivers para CLPs Rockwell;
KEPServerEx com suite de suite de driver para o protocolo BACnet;
KEPServerEx com suite de suite de drivers para Modbus e suite de drivers para CLPs Siemens.

Explicação:

KEPServerEx com suite de suite de drivers para CLPs Rockwell - estamos especificando todas as intefaces de comunicação (porque especificamos um KEPServerEx) e estamos especificando todos os drivers de comunicação que a Kepware dispõe para comunicar com os equipamentos da Rockwell.
Neste caso o programa (ou os programas) que se comunicar(em) com o KEPServerEx vão ter acesso a CLPs Allen-Bradley, de fabricação da Rockwell.

KEPServerEx com suite de suite de driver para protocolo BACnet - estamos especificando todas as intefaces de comunicação (porque especificamos um KEPServerEx) e estamos especificando o driver para o protocolo BACnet com isto podemos comunicar com os equipamentos que implementam este protocolo.
Neste caso o programa (ou os programas) que se comunicar(em) com o KEPServerEx vão ter acesso a equipamentos de diversos fabricantes que implementam o protocolo BACnet.

KEPServerEx com suite de suite de drivers para Modbus e suite de drivers para CLPs Siemens - estamos especificando todas as intefaces de comunicação (porque especificamos um KEPServerEx), estamos especificando todos os drivers que a Kepware dispõe  para o protocolo Modbus e com isto podemos comunicar com os equipamentos que implementam este protocolo, e estamos também especificando todos os drivers de comunicação que a Kepware dispõe para comunicar com os equipamentos da Siemens.
Neste caso o programa (ou os programas) que se comunicar(em) com o KEPServerEx vão ter acesso a a equipamentos de diversos fabricantes que implementam o protocolo Modbus e CLPs da família S5 e S7, de fabricação da Siemens.