RedundancyMaster

O RedundancyMaster aumenta a confiabilidade e a disponibilidade dos seus dados OPC, permitindo que vários servidores OPC sejam configurados em pares redundantes. Cada par redundante aparece perfeitamente como um único servidor OPC para qualquer aplicativo cliente OPC. O RedundancyMaster pode ser adicionado a um aplicativo cliente / servidor existente sem nenhuma reconfiguração do aplicativo, mantendo seus processos sem tempo de inatividade.

A tecnologia OPC Data Access (OPC DA) provou ser confiável em praticamente todos os ambientes industriais que exigem acesso consistente a dados de dispositivos e sistemas. No entanto, existem outros fatores que podem comprometer a integridade de um sistema, incluindo software, hardware e até erro humano. Ao usar a tecnologia de redundância OPC, você pode ajudar a tornar esses sistemas mais confiáveis ​​e eficientes.

O RedundancyMaster reside em sua máquina cliente OPC e facilita as conexões com um servidor OPC primário e secundário nas redes do sistema “conectando” as chamadas OPC feitas entre o cliente e o servidor. Se, por qualquer motivo, o cliente OPC perder seu link de comunicação com o servidor OPC principal ou se uma condição especificada pelo usuário for atendida (como um item não está recebendo atualizações, um valor específico é atendido ou a qualidade de um item é definida como ruim), o RedundancyMaster interromperá o servidor OPC principal e promoverá o servidor OPC secundário em sua rede  reduzindo o tempo de inatividade do sistema e economizando dinheiro.

O RedundancyMaster é um aplicativo drop-in que não exige que você faça alterações nos aplicativos cliente ou servidor OPC. Sua configuração intuitiva leva apenas alguns minutos e permitirá que você estabeleça facilmente um sistema OPC redundante. Simplesmente navegue e selecione seus servidores OPC primário e secundário e, em seguida, seu sistema estará em funcionamento. O RedundancyMaster inclui recursos como notificação por email, monitoramento de objetos e links e log de diagnóstico. Na situação em que você precisa de vários pares de servidores OPC redundantes que utilizam o mesmo fornecedor de servidor OPC, adicionamos a capacidade de alias o ProgID (Program ID) do servidor OPC. (O aliasing pode exigir pequenas modificações no cliente OPC.)

Recursos

Explore os recursos que mudarão como você pensa sobre a redundância de OPC. As inovações no RedundancyMaster podem trabalhar em conjunto com o aplicativo OPC atual para oferecer uma solução mais confiável e econômica.

Procure a máquina principal que especifica a conexão preferida que deve ser feita com um servidor OPC e a máquina secundária que especifica a conexão de fallback que deve ser feita com um servidor OPC quando as comunicações com a máquina principal não estiverem disponíveis. Sempre que uma nova conexão do cliente é estabelecida com o servidor subjacente, o aplicativo tenta primeiro fazer uma conexão com o servidor em execução na máquina principal. Caso a conexão ao primário falhe ou a comunicação com o primário seja perdida, uma conexão com o servidor secundário será tentada e, se disponível, estabelecida. Dependendo do modo de conexão, você pode configurar o aplicativo para estabelecer automaticamente as comunicações com a máquina principal quando ela estiver disponível.

O modo de conexão define como e quando o aplicativo de redundância deve se conectar aos servidores primário e secundário subjacentes. O modo em que você opera afeta a quantidade de tempo que leva para realizar o failover de um servidor OPC para outro. Alguns modos permitem promover automaticamente as comunicações com o primário, quando disponíveis. A seguir, são apresentados os modos de conexão:


Frio (somente máquina ativa):Nesse modo, o aplicativo se conectará apenas a um servidor subjacente por vez. Na inicialização, será feita uma conexão com o servidor principal e todas as solicitações relacionadas ao cliente serão encaminhadas para o primário. No caso de falha na conexão com o primário ou perda de comunicação com o primário, será feita uma conexão com o secundário. Se o aplicativo de redundância não conseguir obter uma conexão com o secundário, ele continuará fazendo ping-pong entre os dois servidores até que faça uma conexão bem-sucedida.

O modo de conexão “fria” minimiza a quantidade de recursos do sistema que são alocados, pois haverá apenas uma conexão com um servidor a qualquer momento. Também reduz o tráfego da rede, pois não há necessidade de pesquisar a máquina inativa além da máquina ativa, como em outros modos. A desvantagem dessa configuração é a quantidade de tempo que leva para realizar o failover no servidor inativo. Quando a perda de comunicação é detectada com o servidor ativo, o aplicativo precisa estabelecer a conexão com o servidor inativo, assinar todos os itens em nome do cliente e iniciar os mecanismos de retorno de chamada apropriados.

Quente (ambas as máquinas, assine itens na máquina ativa):Nesse modo, o aplicativo tentará manter uma conexão com os servidores primário e secundário o tempo todo. Somente itens no servidor principal estarão ativos e pesquisados. Caso a conexão com o primário falhe ou as comunicações com o primário sejam perdidas, os itens idênticos no servidor principal serão configurados para ativos no servidor secundário. Periodicamente, os dois servidores receberão ping para determinar se a conexão ainda é válida.

A conexão “quente” aumenta a quantidade de recursos do sistema alocados, pois haverá duas conexões de servidor feitas em nome do cliente. Também há um aumento mínimo no tráfego de rede devido ao ping periódico de dois servidores em vez de um, como na operação no modo “frio”. Os benefícios são que o tempo de failover é minimizado na operação no modo “frio”, pois o aplicativo de redundância precisará inicializar apenas os retornos de chamada de dados no servidor inativo para começar a receber dados. Se você precisar minimizar a perda de dados em seu aplicativo e, ao mesmo tempo, minimizar o tráfego de rede, use este modo de conexão.

Quente (ambas as máquinas, assine itens nas duas máquinas):Nesse modo, o aplicativo tentará manter uma conexão com os servidores primário e secundário o tempo todo. Na inicialização, o aplicativo inicializará retornos de chamada de dados para servidores primário e secundário, para que ambos enviem notificações de alteração de dados. Os dados recebidos do servidor principal serão encaminhados para o cliente. Caso a conexão com o primário falhe ou a comunicação com o primário seja perdida, os dados recebidos pelo secundário serão encaminhados imediatamente para o cliente. Nos dois casos, as gravações serão encaminhadas apenas para o servidor ativo. Periodicamente, os dois servidores receberão ping para determinar se as conexões ainda são válidas. Se a qualquer momento o aplicativo de redundância perder a comunicação com qualquer servidor, ele tentará periodicamente se reconectar ao servidor com falha. Essa configuração aumenta a quantidade de recursos do sistema alocados, pois haverá duas conexões de servidor feitas em nome do cliente. Também há um aumento no tráfego de rede devido ao recebimento de notificações de alteração de dados de ambos os servidores subjacentes, bem como ao ping periódico dos dois servidores para determinar se eles ainda estão disponíveis. O benefício dessa configuração é que o tempo de failover ocorre imediatamente após a detecção da perda do servidor ativo. Se a perda de dados é muito crucial para o seu aplicativo, você deve usar este modo de conexão. além de efetuar ping periodicamente nos dois servidores para determinar se eles ainda estão disponíveis. O benefício dessa configuração é que o tempo de failover ocorre imediatamente após a detecção da perda do servidor ativo. Se a perda de dados é muito crucial para o seu aplicativo, você deve usar este modo de conexão. além de efetuar ping periodicamente nos dois servidores para determinar se eles ainda estão disponíveis. O benefício dessa configuração é que o tempo de failover ocorre imediatamente após a detecção da perda do servidor ativo. Se a perda de dados é muito crucial para o seu aplicativo, você deve usar este modo de conexão.

Esse recurso permite configurar vários pares de servidores OPC com o mesmo ProgID. Esse recurso permite que você use um fornecedor de servidor OPC se você tiver vários nós de servidor OPC em sua rede. Isso permitirá que os clientes OPC se conectem a um par redundante específico, consultando o ProgID alternativo desse par redundante.

Essa configuração permite que o RedundancyMaster promova automaticamente as comunicações de volta para a máquina principal quando o servidor OPC estiver disponível.

Esse intervalo (especificado em milissegundos) determina com que frequência o RedundancyMaster efetuará ping nos servidores subjacentes para determinar se houve uma perda de comunicação. Ao consultar a uma taxa mais rápida, você pode minimizar o tempo de failover, pois a detecção de falhas ocorre com mais frequência.

Esse intervalo (especificado em milissegundos) determina quanto tempo o aplicativo de redundância aguardará uma resposta de ping dos servidores subjacentes antes de considerar a perda de comunicações.

Esse recurso permite configurar determinadas condições que iniciarão um failover no servidor inativo. Essas condições permitem monitorar itens de servidor para estados específicos para determinar a integridade dos servidores / dispositivos subjacentes, além do failover automático que ocorrerá devido à perda de comunicações.

Os eventos podem ser preservados em disco quando o aplicativo é encerrado. Na próxima vez que o aplicativo for iniciado, os eventos serão exibidos e quaisquer novos eventos serão concatenados até o final da visualização.

Como o diagnóstico utiliza recursos de memória e armazenamento, você pode limitar o número de diagnósticos preservados a qualquer momento. O RedundancyMaster permite definir o número máximo de eventos a serem capturados. Quando o número máximo de eventos for atingido, os eventos mais antigos serão descartados conforme necessário.

Esse recurso permite configurar um ou mais destinatários para receber notificações por email para um ou mais eventos de diagnóstico. Os eventos disponíveis para envio como notificações por email são os mesmos visíveis para a visualização de evento local das Configurações de diagnóstico.

Cenários de casos de uso

Existem muitas variáveis ​​que podem afetar a qualidade e a confiabilidade de seus dados ou fazer com que um sistema OPC perca a conexão com um servidor OPC. Os mais comuns incluem:

  • O PC executando o servidor OPC está desligado
  • Erros de usuário fazem com que o servidor OPC saia
  • A conexão de rede com o servidor OPC está perdida ou não é confiável
  • A configuração de rede é alterada, causando falha no link
  • O próprio servidor OPC falha por qualquer motivo, conhecido ou não
  • A conta de login é alterada no PC do servidor OPC

Na maioria dos casos acima, o servidor OPC DA falha ao fornecer dados devido a uma falha real subjacente ao servidor OPC ou à conexão com esse servidor. Esses tipos de falhas são conhecidas como falhas “baseadas em objeto”. As falhas baseadas em objeto ocorrem quando o link real entre o aplicativo cliente OPC e o servidor OPC de destino é interrompido. Nestes exemplos, o software está com defeito. No entanto, falhas de hardware físico em um aplicativo também podem afetar drasticamente a confiabilidade. Alguns desses fatores físicos incluem:

  • Falha na conexão física (o cabo está puxado)
  • Falha no hardware (falha do roteador)
  • Interferência elétrica (descarga de alta corrente)
  • Atrasos devido à propagação do sinal (links de rádio)
  • Fatores ambientais (raios)
  • Acidentes aleatórios

Nessas situações, a conexão virtual entre o servidor OPC e o cliente pode estar perfeitamente intacta, mas o link físico para o dispositivo ou sistema subjacente pode ser interrompido. Esses tipos de falhas são conhecidas como falhas “baseadas em link”. As falhas baseadas em link ocorrem quando a conexão com o dispositivo ou sistema de destino é perdida. Na maioria dos casos, o servidor OPC ainda está completamente operacional, mas simplesmente não pode fornecer os dados para o restante do sistema.

O RedundancyMaster pode ser configurado para monitorar essas condições e evitar paradas desnecessárias no sistema, economizando tempo e dinheiro.

Se vários aplicativos clientes do OPC DA estiverem acessando um único servidor OPC, o potencial existe para uma falha baseada em objeto ou uma falha baseada em link. Se, por qualquer motivo, o servidor OPC único não funcionar, poderá ocorrer uma falha baseada em objeto. Além disso, como esse único PC é responsável pela coleta de dados dos dispositivos subjacentes, existe um único ponto de falha para as conexões do dispositivo.

Para aumentar a confiabilidade do seu sistema OPC, você precisa remover esses pontos únicos de falha redesenhando seu sistema OPC para usar mais de um servidor OPC. Para facilitar a operação redundante dos servidores OPC, cada cliente OPC é emparelhado com o RedundancyMaster.

Usando as opções configuráveis ​​no RedundancyMaster, o uso do servidor OPC Primário ou Secundário pode ser controlado diretamente. Com base nos modos selecionados, o RedundancyMaster manterá os dois servidores ativos ou (se configurado para isso) iniciará o servidor secundário apenas quando o servidor principal falhar.

Frio (somente máquina ativa):Nesse modo, o aplicativo se conectará apenas a um servidor subjacente por vez. Na inicialização, será feita uma conexão com o servidor principal e todas as solicitações relacionadas ao cliente serão encaminhadas para o primário. No caso de falha na conexão com o primário ou perda de comunicação com o primário, será feita uma conexão com o secundário. Se o aplicativo de redundância não conseguir obter uma conexão com o secundário, ele continuará fazendo ping-pong entre os dois servidores até que faça uma conexão bem-sucedida.

O modo de conexão “fria” minimiza a quantidade de recursos do sistema que são alocados, pois haverá apenas uma conexão com um servidor a qualquer momento. Também reduz o tráfego da rede, pois não há necessidade de pesquisar a máquina inativa além da máquina ativa, como em outros modos. A desvantagem dessa configuração é a quantidade de tempo que leva para realizar o failover no servidor inativo. Quando a perda de comunicação é detectada com o servidor ativo, o aplicativo precisa estabelecer a conexão com o servidor inativo, assinar todos os itens em nome do cliente e iniciar os mecanismos de retorno de chamada apropriados.

Quente (ambas as máquinas, assine itens na máquina ativa):Nesse modo, o aplicativo tentará manter uma conexão com os servidores primário e secundário o tempo todo. Somente itens no servidor principal estarão ativos e pesquisados. Caso a conexão com o primário falhe ou as comunicações com o primário sejam perdidas, os itens idênticos no servidor principal serão configurados para ativos no servidor secundário. Periodicamente, os dois servidores receberão ping para determinar se a conexão ainda é válida.

A conexão “quente” aumenta a quantidade de recursos do sistema alocados, pois haverá duas conexões de servidor feitas em nome do cliente. Também há um aumento mínimo no tráfego de rede devido ao ping periódico de dois servidores em vez de um, como na operação no modo “frio”. Os benefícios são que o tempo de failover é minimizado na operação no modo “frio”, pois o aplicativo de redundância precisará inicializar apenas os retornos de chamada de dados no servidor inativo para começar a receber dados. Se você precisar minimizar a perda de dados em seu aplicativo e, ao mesmo tempo, minimizar o tráfego de rede, use este modo de conexão.

Quente (ambas as máquinas, assine itens nas duas máquinas):Nesse modo, o aplicativo tentará manter uma conexão com os servidores primário e secundário o tempo todo. Na inicialização, o aplicativo inicializará retornos de chamada de dados para servidores primário e secundário, para que ambos enviem notificações de alteração de dados. Os dados recebidos do servidor principal serão encaminhados para o cliente. Caso a conexão com o primário falhe ou a comunicação com o primário seja perdida, os dados recebidos pelo secundário serão encaminhados imediatamente para o cliente. Nos dois casos, as gravações serão encaminhadas apenas para o servidor ativo. Periodicamente, os dois servidores receberão ping para determinar se as conexões ainda são válidas. Se a qualquer momento o aplicativo de redundância perder a comunicação com qualquer servidor, ele tentará periodicamente se reconectar ao servidor com falha. Essa configuração aumenta a quantidade de recursos do sistema alocados, pois haverá duas conexões de servidor feitas em nome do cliente. Também há um aumento no tráfego de rede devido ao recebimento de notificações de alteração de dados de ambos os servidores subjacentes, bem como ao ping periódico dos dois servidores para determinar se eles ainda estão disponíveis. O benefício dessa configuração é que o tempo de failover ocorre imediatamente após a detecção da perda do servidor ativo. Se a perda de dados é muito crucial para o seu aplicativo, você deve usar este modo de conexão. além de efetuar ping periodicamente nos dois servidores para determinar se eles ainda estão disponíveis. O benefício dessa configuração é que o tempo de failover ocorre imediatamente após a detecção da perda do servidor ativo. Se a perda de dados é muito crucial para o seu aplicativo, você deve usar este modo de conexão. além de efetuar ping periodicamente nos dois servidores para determinar se eles ainda estão disponíveis. O benefício dessa configuração é que o tempo de failover ocorre imediatamente após a detecção da perda do servidor ativo. Se a perda de dados é muito crucial para o seu aplicativo, você deve usar este modo de conexão.

Nesse cenário, o cliente OPC, RedundancyMaster e o servidor OPC secundário, todos residem na máquina local e o servidor OPC principal reside em uma máquina remota. Para este sistema, certifique-se de tornar o servidor mais confiável seu servidor OPC secundário. Esse cenário reduz a necessidade de outra máquina executar o servidor OPC secundário.

O RedundancyMaster pode ser configurado para ter vários pares de servidores OPC. Nesse cenário, existem dois pares de servidores OPC que estão coletando dados de duas redes de dispositivos separadas. Se os vários pares de servidores OPC forem todos do mesmo ProgID, será necessário usar o recurso Aliasing. Se os dois pares tiverem servidores OPC diferentes com ProgIDs diferentes, você não precisará usar o recurso Aliasing.