Série Nexto - Configuração de CPU Nexto Redundante com Remotas MODBUS

Este documento tem como objetivo orientar desenvolvedores de sistemas, como configurar uma arquitetura de CPs redundantes da série Nexto, NX3030, utilizando as E/S do sistema acionadas por remotas MODBUS.

 

O objetivo principal é orientar a implementação da aplicação.

Para o melhor entendimento do funcionamento dos equipamentos é recomendado que o Manual de Usuário UCPs Série Nexto (MU214100) e o Manual de Utilização MasterTool IEC XE (MU299048) sejam consultados. A mesma recomendação aplica-se caso seja necessário modificar a arquitetura proposta como exemplo.

 

 

1. Introdução

A Série Nexto é uma poderosa e completa série de Controladores Programáveis (CP) com características exclusivas e inovadoras. Devido a sua flexibilidade, design funcional, recursos de diagnóstico avançado e arquitetura modular, o CP Nexto pode ser usado para controle de sistemas em aplicações de pequeno, médio ou grande porte.

A arquitetura da Série Nexto fornece uma grande variedade de módulos de entradas e saídas. Estes módulos, combinados com uma poderosa UCP de 32 bits e um barramento baseado em Ethernet de alta velocidade, atendem a muitas aplicações de usuário, tais como controle rápido de máquinas, complexas aplicações de processos distribuídos e redundantes, ou até mesmo grandes sistemas de E/S para automação predial. Entre outras funcionalidades, a Série Nexto oferece módulos para controle de movimento, comunicação e interfaces com as mais conhecidas redes de campo.

A tecnologia de barramento utilizada na série é baseada em Ethernet de alta velocidade, a qual permite que as entradas, saídas e informações processadas sejam compartilhadas entre todos os módulos do sistema. Os módulos de E/S podem ser facilmente distribuídos no campo, e podem ser usados tanto E/S locais quanto remotas, sem nenhuma perda no desempenho.

Adicionalmente, a Série Nexto apresenta uma ferramenta completa para programação, configuração, simulação e depuração da aplicação do usuário: o MasterTool IEC XE. Trata-se de um software flexível e de fácil utilização que oferece seis linguagens de programação definidas pela norma IEC 61131-3: Texto Estruturado (ST), Sequenciamento Gráfico de Funções (SFC), Diagrama de Blocos Funcionais (FBD), Diagrama Ladder (LD), Lista de instruções (IL) e Gráfico Funcional Continuo (CFC). O MasterTool IEC XE permite o uso de diferentes linguagens na mesma aplicação, fornecendo ao usuário uma poderosa forma de organizar a aplicação e reaproveitar códigos usados em aplicações anteriores.

A CPU NX3030 pode operar em redundância do tipo hot-standby, onde os controladores são duplicados. Um dos controladores normalmente está em estado Ativo e controlando o processo, enquanto o outro controlador normalmente está em estado Reserva, mantendo-se sincronizado com o controlador Ativo. Caso ocorra uma falha no controlador Ativo, que o impeça de continuar controlando o processo, o controlador Reserva chaveia automaticamente para Ativo, em um tempo suficientemente baixo para não perturbar o processo, sem causar descontinuidades nas saídas que controlam o processo.

A redundância hot-standby é um método utilizado para aumentar a tolerância a falhas e, consequentemente, aumentar a disponibilidade do sistema de automação. A ideia básica é que nenhuma falha simples em componentes duplicados cause a interrupção do controle do processo.

• A redundância hot-standby é muito aplicada em:
• plataformas de exploração de petróleo
• sistemas de geração e distribuição de energia
• intertravamentos de segurança (Sistemas Instrumentados de Segurança)
• processos contínuos, tais como plantas químicas, refinarias de petróleo, produção de celulose, etc.

Além dos controladores, podem ser também duplicadas, opcionalmente, as redes de campo (PROFIBUS DP), as redes de supervisão Ethernet, e as redes de controle Ethernet HSDN (High Speed Deterministic Network). Optando-se pela duplicação destas redes, obtém-se uma disponibilidade ainda maior.

A redundância hot-standby de CPs da Série Nexto não prevê duplicação de módulos de E/S. Caso a redundância de módulos de E/S seja desejável, ela pode ser tratada em nível de aplicação, pelo usuário final. Por exemplo, o usuário pode duplicar ou até mesmo triplicar um módulo de entradas analógicas, e criar um algoritmo de votação para determinar qual das entradas irá ser considerada em determinado momento em sua aplicação.

Uma solução de baixo custo e que garante a confiabilidade do sistema, é a configuração de uma arquitetura de CPs redundante com o acionamento dos módulos de E/S através de remotas MODBUS, através de rede simples ou redundante.

 

 

2. Definição da Arquitetura de Referência

A seguir mostra-se um exemplo de uma arquitetura redundante com E/S acionadas por remotas MODBUS.

 

Material Utilizado no Exemplo

Dentre os itens utilizados para a construção de um sistema redundante de referência temos:

CP Redundante:

• dois half-clusters idênticos
• painel de controle de redundância PX2612
• 2 cabos AL-2319 (interligações NETA e NETB entre CPA e CPB)
• 1 cabo AL-2317/A (interligação entre CPA e PX2612)
• 1 cabo AL-2317/B (interligação entre CPB e PX2612)

Cada half-cluster é constituído, no mínimo, dos seguintes módulos:

• o próprio bastidor onde os módulos são inseridos, que pode ser o NX9001, com 12 posições, NX9002, com 16 posições ou o NX9003, com 24 posições
• a fonte de alimentação NX8000, nas posições 0 e 1 do bastidor
• a UCP NX3030, nas posições 2 e 3 do bastidor
• o módulo NX4010, nas posições 4 e 5 do bastidor

A Figura 1 mostra um exemplo de configuração mínima de um CP redundante, utilizando o menor bastidor (NX9001, com 12 posições). Neste caso, observa-se que os 3 módulos inseridos no bastidor têm largura dupla (ocupam duas posições do bastidor).

Figura 1. Sistema Redundante com Remotas MODBUS

 

 

3. Configuração do CP Redundante

Para criar um projeto e configurar um sistema redundante NX3030, deve-se utilizar o software MasterTool IEC XE.

Não será descrito aqui o processo de instalação e autorização de funcionamento do software MasterTool IEC XE. Considera-se que o mesmo já esteja instalado, configurado e funcionando perfeitamente em um computador.

 O Software MasterTool IEC XE utilizado no desenvolvimento abaixo é de versão 1.23.

 

 

3.1. Novo Projeto

Neste capítulo, será abordada a criação de um novo projeto a partir do perfil Simples, utilizando a ferramenta "Wizard", a qual apresenta as opções de configuração do sistema ao usuário.

Inicialmente, o usuário deverá criar um novo projeto no MasterTool IEC XE a partir do menu Arquivo e logo em seguida, "Novo Projeto...", conforme mostra a Figura 2:

 

Figura 2. Novo Projeto

 

Após, uma janela será apresentada ao usuário, solicitando que o mesmo selecione o tipo de projeto que deseja fazer e, em seguida, escreva um nome e a localização para armazenar o projeto no computador. Clicar em OK para prosseguir ou Cancelar para interromper.

 

Figura 3. Classificação do Projeto

 

A seguir, o usuário deverá selecionar a UCP desejada, os módulos de hardware básicos que compõem o barramento, ou seja, o modelo de bastidor e de fonte de alimentação e a configuração de redundância. Nesse caso, será utilizada a UCP NX3030 (com redundância), um bastidor NX9001 e uma fonte de alimentação NX8000.

 Figura 4. Módulos de Hardware

 

Na janela de configuração de redes, o usuário deverá selecionar a quantidade de redes PROFIBUS e a quantidade de redes Ethernet adicionais. No exemplo proposto não utilizaremos nenhuma rede adicional.

Figura 5. Quantidade de Redes PROFIBUS e Ethernet

 

Então, o usuário deverá selecionar a linguagem padrão para as POUs (programas). Nesse caso o novo projeto está exemplificado perfil Simples e linguagem ST.

 

Figura 6. Seleção da Linguagem Padrão

 

A próxima tela define a linguagem das POUs de usuário não redundante (NonSkippedPrg) e redundante (ActivePrg) . Clicar em Anterior para voltar à tela antecedente, Concluir para finalizar ou Cancelar para interromper.

 

Figura 7. Linguagem dos Programas das Tarefas Principais

 

Ao pressionar o botão Concluir, o MasterTool IEC XE iniciará a criação do ambiente de desenvolvimento do projeto. Esse procedimento pode levar alguns segundos.

 

 

4. Configurações das Portas Ethernet da UCP NX3030 (NET 1 e NET 2)

4.1. Configuração do Endereço de IP

A Figura 8 mostra as configurações da porta NET 1 da UCP NX3030. Para abrir esta tela, deve-se dar um duplo clique sobre NET 1, abaixo da UCP NX3030 na árvore de dispositivos. Nesta tela deve-se definir o IP que o CP vai assumir quando operar no modo ativo e os IPs de cada Half-Cluster.

 

Figura 8. Parâmetros da Porta Ethernet NET 1

 

 

4.2. NIC Teaming entre NET 1 e NET 2

A opção Avançado, na tela de configuração da interface NET 1, abre uma nova tela de configuração, a qual define se NET 1 será redundante. Habilitando o checkbox de Redundância de Comunicação, as interfaces NET 1 e NET 2 formarão um par redundante com NIC Teaming. Automaticamente, outros parâmetros serão habilitados e deverão ser configurados:

• Período de Teste da Redundância (ms): Período de envio do frame de teste de comunicação entre as duas NETs. Pode ser configurado com valores entre 100 e 9900.

• Número de Retentativas do Teste da Redundância: Numero máximo de vezes que a NET que enviou o frame irá esperar pela resposta. Pode ser configurado com valores entre 1 e 100.

• Período para Chaveamento (s): Tempo máximo que a NET Ativa irá esperar por um pacote qualquer. Pode ser configurado com valores entre 1 e 25.

 

Figura 9. Configurações Avançadas da Ethernet

 

Caso o tempo de resposta do Teste da Redundância atinja Período de Teste vezes o Número de Retentativas e a interface ativa permaneça por um tempo maior que o Período para Chaveamento sem receber nenhum pacote, ocorrerá um switchover, tornando ativa a interface que até então estava inativa. É importante ressaltar que há um delay entre a detecção da falha e ativação da interface inativa devido ao tempo necessário para sua configuração. Tal delay pode chegar a algumas dezenas de milisegundos.

Quando uma das NETs estiver ativa, esta assumirá o endereço de IP configurado, permanecendo a NET inativa com seus parâmetros de Endereço de IP, Máscara de Subrede e Endereço do Gateway em branco nos diagnósticos da UCP. 

 

 

5. Configuração da rede MODBUS

O primeiro passo para configurar a rede MODBUS é incluir uma instância na NET desejada (neste caso NET 1, pois a UCP NX3030 está operando com NIC Teaming entre NET 1 e NET 2). Clicar com o botão direito sobre a NET 1 e selecionar "Acrescentar Dispositivo...", conforme mostra a Figura 10:

 

Figura 10. Adicionando a Instância

 

Após, surgirá na tela os protocolos disponíveis ao usuário. Nesse caso, "MODBUS Ethernet Client" e "MODBUS Ethernet Server". Clicar em Acrescentar, conforme mostra a Figura 11:

 

Figura 11. Selecionando o Protocolo

 

 

5.1. MODBUS Client

Conforme a Figura 11, acrescentar uma instância MODBUS Cliente. 

O próximo passo indica a inserção de uma relação MODBUS cliente, Figura 4 11. No exemplo em questão serão inseridos quatro clientes MODBUS. Um para a comunicação entre o CP ativo e CPA e outro para a comunicação entre CP ativo e CPB, os outros dois clientes são destinados para a comunicação com duas remotas MODBUS. 

Todos os comandos e diagnósticos referentes aos clientes MODBUS devem ser mapeados em áreas de memória não redundante.

 Figura 12. Inserção das Relações MODBUS Client

 

O próximo passo, Figura 13 e Figura 14, indica a inserção dos mapeamentos MODBUS em cada Cliente. Cada cliente que comunica o CP ativo com os CPA e CPB, deve possuir uma relação de Hoding Register de 120 posições, iniciando do endereço 1. A área de memória mapeada nos diagnósticos deve ser não redundante.

Os Clientes referentes às remotas MODBUS, devem ter seus diagnósticos mapeados em áreas não redundantes, e as áreas de memória referentes às E/S devem ser áreas redundantes.

 Figura 13. Mapeamento das Relações MODBUS

 

 

Figura 14. Tela de Mapeamento de uma Relação MODBUS

 

 

5.2. Mapeamento MODBUS Cliente

Segue abaixo o mapeamento MODBUS Cliente utilizado no exemplo:

Tabela 1. Configuração do Cliente MODBUS

 

A tabela abaixo descreve a configuração MODBUS utilizada para comunicar o CP ativo com o CPA:

Tabela 2. Dispositivo 0

 

A tabela abaixo descreve a configuração MODBUS utilizada para comunicar o CP ativo com o CPB:

Tabela 3. Dispositivo 1

 

A tabela abaixo descreve a configuração MODBUS utilizada para comunicar o CP ativo com a remota MODBUS 1. O mapeamento 0 se refere aos pontos de saída que serão acionados e o mapeamento 1 se refere os pontos de entrada que serão lidos da remota MODBUS.

O usuário pode inserir outros mapeamentos, a fim de ampliar a quantidade de pontos E/S controlados na remota MODBUS. 

Tabela 4. Dispositivo 2

 

A tabela abaixo descreve a configuração MODBUS utilizada para comunicar o CP ativo com a remota MODBUS 2. O mapeamento 0 se refere aos pontos de saída que serão acionados e o mapeamento 1 se refere os pontos de entrada que serão lidos da remota MODBUS.

O usuário pode inserir outros mapeamentos, a fim de ampliar a quantidade de pontos E/S controlados na remota MODBUS. 

Tabela 5. Dispositivo 3

 

 

5.3. MODBUS Server

Conforme a Figura 11, acrescentar uma instância MODBUS Server. 

O próximo passo indica a inserção de uma relação MODBUS Servidor, Figura 15. No exemplo em questão é inserido um servidor MODBUS, para a comunicação entre CP ativo e CP não ativo. 

Todos os comandos e diagnósticos referentes ao servidor MODBUS devem ser mapeado em áreas de memória não redundante.

Figura 15. Inserção da Relação MODBUS Server

 

 

Figura 16. Tela de Mapeamento de uma Relação MODBUS Server

 

5.4. Mapeamento MODBUS Servidor

Segue abaixo o mapeamento MODBUS Servidor utilizado no exemplo:

Tabela 6. Configuração do Servidor MODBUS

 

Tabela 7. Relação 0 - Holding Register

 

6. Código Fonte

Este capitulo descreve o código fonte a ser inserido pelo usuário na aplicação, afim gerenciar a comunicação com as remotas MODBUS e o comportamento do sistema redundante em caso de falha.

 

6.1 Criando as POUs

Uma POU (Program Organization Unit, ou Unidade de Organização de Programa), é uma subdivisão do programa aplicativo que pode ser escrito em qualquer uma das linguagens disponíveis no software MasterTool IEC XE.

Com a criação do projeto através de um perfil selecionado, algumas POUs já são criadas, porém o usuário poderá criar quantas quiser, limitado pelo tamanho máximo da memória de programa.

Para inserir uma nova POU, basta clicar com o botão direito sobre o nome da aplicação, (nome padrão criado para a aplicação é "Application"), selecionar "Acrescentar Objeto" e, então, "POU...", conforme mostra a Figura 17: 

 

Figura 17. Inserindo POUs

 

Uma janela de configuração irá surgir na tela, na qual o usuário deve colocar o nome da POU, selecionar o tipo e a linguagem que se deseja implementar. A seguir, deve clicar em Abrir.

Figura 18. Classificando a POU

 

Para editar a POU basta selecionar a aba com o nome correspondente e iniciar o desenvolvimento da aplicação na linguagem escolhida anteriormente. O mesmo procedimento é válido para as POUs criadas automaticamente pelo perfil do projeto.

Figura 19. Editando a POU

 

6.2. MODBUS_Manager

A POU MODBUS_Manager, do tipo programa, é responsável pelo gerenciamento das relações MODBUS e Switchover entre CPs. 

De acordo com o código exemplificado abaixo, se ocorrerem falhas MODBUS na comunicação entre Clusters e entre o CP Ativo e as remotas, será executado um Switchover.

O tempo de Switchover é a soma do tempo configurado no temporizador TemporizadorSwitchoverMasterModBus com o tempo que leva para ser detectada a falha na função FALHA_MODBUSClient. Este deve ser maior que o Timeout e maior que o Período para Chaveamento do NIC Teaming.

Caso o usuário deseje incluir novas remotas MODBUS, deve-se incluir na linha "// Calcula falha geral Master ModBus", sua consistência de falha.

 

Código Fonte:

PROGRAM MODBUS_Manager

VAR

TemporizadorSwitchoverMasterModBus : TON_NR;

EstadoAtivo : BOOL;

EstadoReserva : BOOL;

EstadoInativo : BOOL;

EstadoOutroReserva : BOOL;

ExecutarSwitchoverMasterModBus : BOOL;

AguardarStandby : BOOL;

ChavearInativo : BOOL;

eRedStateLocal: BYTE;

eRedStateLocal_old: BYTE;

END_VAR

EstadoAtivo := (DG_NX4010.tRedundancy.RedDgnLoc.sGeneral_Diag.eRedState = REDUNDANCY_STATE.ACTIVE);

EstadoReserva := (DG_NX4010.tRedundancy.RedDgnLoc.sGeneral_Diag.eRedState = REDUNDANCY_STATE.STANDBY);

EstadoInativo := (DG_NX4010.tRedundancy.RedDgnLoc.sGeneral_Diag.eRedState = REDUNDANCY_STATE.INACTIVE);

EstadoOutroReserva := (DG_NX4010.tRedundancy.RedDgnRem.sGeneral_Diag.eRedState = REDUNDANCY_STATE.STANDBY) AND

DG_NX4010.tRedundancy.RedDgnLoc.sGeneral_Diag.bExchangeSync;

// Leitura do estado atual do CP local

eRedStateLocal := DG_NX4010.tRedundancy.RedDgnLoc.sGeneral_Diag.eRedState;

// O estado do CP local mudou?

IF eRedStateLocal <> eRedStateLocal_old THEN 

IF eRedStateLocal = REDUNDANCY_STATE.ACTIVE THEN 

// CP local entrou em estado Ativo

Diagnostics.DG_MODBUS_Client.tCommand.bRestart:= TRUE;

ELSE

// CP local entrou em um estado Não Ativo

Diagnostics.DG_MODBUS_Client.tCommand.bStop:= TRUE;

END_IF

// Salva o último estado do CP local

eRedStateLocal_old:= eRedStateLocal;

END_IF

// Lógica de falha geral Master ModBus - Switchover

FAL_GERAL_MODBUS:= (FAL_MODBUS_NACT_PLCA OR FAL_MODBUS_NACT_PLCB) AND FAL_REMOTA_MODBUS_01 AND FAL_REMOTA_MODBUS_02;

// Gerencia switchover automático do Master ModBus

TemporizadorSwitchoverMasterModBus(IN := FAL_GERAL_MODBUS AND EstadoAtivo AND EstadoOutroReserva, PT := T#5S, Q => ExecutarSwitchoverMasterModBus);

IF ExecutarSwitchoverMasterModBus THEN

DG_NX4010.tRedundancy.RedCmdLoc.bStandbyLocal := TRUE;

AguardarStandby := TRUE;

END_IF

IF (AguardarStandby AND EstadoReserva) THEN

DG_NX4010.tRedundancy.RedCmdLoc.bInactiveLocal := TRUE;

END_IF

IF EstadoInativo THEN

AguardarStandby := FALSE;

END_IF

 

6.3. FALHA_MODBUSClient

A POU FALHA_MODBUSClient, do tipo função, é responsável por acionar os bits de falha de comunicação caso ocorra algum erro no respectivo cliente MODBUS, pelo tempo especificado na entrada PT.

Caso o usuário deseje incluir novas remotas MODBUS, deve-se incluir novos temporizadores.

 

Código Fonte:

FUNCTION FALHA_MODBUSClient : BOOL

VAR

END_VAR

// Seção para cálculo de falha na comunicação, chamando função de diagnóstico de mapeamento MODBUS

TEMP_FAL_MODBUS_NACT_PLCA(IN:= FALHA_MODBUS_EthMapping(DG_MODBUS_Client, DG_MODBUS_NACT_PLCA_Mapping_000), PT:= T#2500MS, Q=> FAL_MODBUS_NACT_PLCA);

TEMP_FAL_MODBUS_NACT_PLCB(IN:= FALHA_MODBUS_EthMapping(DG_MODBUS_Client, DG_MODBUS_NACT_PLCB_Mapping_000), PT:= T#2500MS, Q=> FAL_MODBUS_NACT_PLCB);

TEMP_FAL_REMOTA_MODBUS_01(IN:= FALHA_MODBUS_EthMapping(DG_MODBUS_Client, DG_REMOTA_MODBUS_01_Mapping_000), PT:= T#2500MS, Q=> FAL_REMOTA_MODBUS_01);

TEMP_FAL_REMOTA_MODBUS_02(IN:= FALHA_MODBUS_EthMapping(DG_MODBUS_Client, DG_REMOTA_MODBUS_02_Mapping_000), PT:= T#2500MS, Q=> FAL_REMOTA_MODBUS_02);

 

6.4. FALHA_MODBUS_EthMapping

Esta POU é do tipo função e é responsável por identificar na estrutura de diagnósticos do cliente MODBUS referenciado, se existe alguma falha.

 

Código Fonte:

FUNCTION FALHA_MODBUS_EthMapping : BOOL

VAR_INPUT

DgClient : T_DIAG_MODBUS_ETH_CLIENT_1;

DgMap : T_DIAG_MODBUS_ETH_MAPPING_1;

END_VAR

VAR

END_VAR

FALHA_MODBUS_EthMapping:= DgClient.tDiag.bNotRunning OR DgMap.byStatus.bCommError OR DgMap.byStatus.bCommAborted;

 

6.5. GVL_MODBUS

Esta lista de variáveis globais declara os temporizadores utilizados para acionar o diagnóstico de falha de um cliente MODBUS, caso ocorra alguma falha por um tempo superior ao definido na função FALHA_MODBUSClient().
Caso o usuário deseja incluir novas remotas MODBUS, deve-se declarar novos temporizadores.

 

Código Fonte:

VAR_GLOBAL

// Temporizador de falha de comunicação com PLCA não ativo

TEMP_FAL_MODBUS_NACT_PLCA: TON;

// Temporizador de falha de comunicação com PLCB não ativo

TEMP_FAL_MODBUS_NACT_PLCB: TON;

// Temporizador de falha de comunicação com a Remota ModBus 01

TEMP_FAL_REMOTA_MODBUS_01: TON;

// Temporizador de falha de comunicação com a Remota ModBus 02

TEMP_FAL_REMOTA_MODBUS_02: TON;

END_VAR

 

 

6.6. GVL_MODBUS_Persist

Esta lista de variáveis globais declara as variáveis do tipo persistente, utilizadas para indicar os clientes MODBUS que apresentam falha.

Caso o usuário deseje incluir novas remotas MODBUS, deve-se declarar novas variáveis.

 

Código Fonte:

VAR_GLOBAL PERSISTENT

FAL_GERAL_MODBUS: BOOL; // Falha de comunicação geral

FAL_MODBUS_NACT_PLCA: BOOL; // Falha de comunicação com PLCA não ativo

FAL_MODBUS_NACT_PLCB: BOOL; // Falha de comunicação com PLCB não ativo

FAL_REMOTA_MODBUS_01: BOOL; // Falha de comunicação com a Remota MODBUS 01

FAL_REMOTA_MODBUS_02: BOOL; // Falha de comunicação com a Remota MODBUS 02

END_VAR

 

 

6.7. NonSkippedPrg

Esta linha de código deve ser copiada dentro da POU NonSkippedPrg.

 

Código Fonte:

// Gerenciamento das Remotas Modbus

MODBUS_Manager();

 

 

6.8. ActivePrg

Esta linha de código deve ser copiada dentro da POU ActivePrg.

 

Código Fonte:

// Tratamento de alarmes Master ModBus Client

FALHA_MODBUSClient();

 

 

7. Redundancy Configuration

A Figura 20 indica quais objetos devem ser selecionados como redundantes através da aba Redundancy Configuration.

 

Figura 20. Redundancy Configuration

 

8. Desempenho

Na arquitetura proposta tanto a CPU redundante, como as Remotas MODBUS, foram configuradas para operar com um tempo de ciclo de execução de aplicação de usuário de 100 ms.

Através desta configuração foi possível obter uma taxa de atualização das entradas e saídas do sistema de 200 ms.

O tempo de execução ocupado pela "MainTask" no CP ativo do sistema redundante foi de 19 ms.