sistema de automação redundante com plc citrino · figura 12.1 – perda do cabo ethernet –...

Manual Técnico Sistema de Automação Redundante com PLC Citrino – MPCU-2 – V1.2 Página 1/58

Sistema de Automação

Redundante com PLC Citrino Manual técnico

22/05/2013 – Versão 1.3 Fertron Controle e Automação Industrial Ltda. Eng. Leonardo Batista de Almeida Scarabelli Eng. Rogério Máximo Rapanello


Conteúdo

Conteúdo ....................................................................................................................................... 2

Índice de tabelas ........................................................................................................................... 4

Índice de figuras ............................................................................................................................ 5

1 Prefácio .................................................................................................................................. 6

2 Apresentação do Sistema Redundante ................................................................................. 7

3 Definições do Sistema de Automação Redundante .............................................................. 8

4 Características de Arquiteturas do Sistema Redundante ...................................................... 9

5 Topologias de Rede Profibus permitidas e não permitidas ................................................. 12

6 Configuração da Redundância com Citrino Tools................................................................ 16

6.1 Configuração dos Módulos Mestres Profibus ................................................... 16

6.2 Configuração dos Parâmetros do Sistema Redundante .................................... 17

7 Inicialização e Operação do Sistema Redundante .............................................................. 20

8 Comportamento do Sistema no momento do Switchover ................................................. 21

8.1 Comportamento dos IPS no momento do Switchover ...................................... 21

8.2 Comando de Switchover pelo Citrino Tools ...................................................... 22

8.3 Comando de Switchover pelo Sistema de Supervisão ou Lógica Ladder .......... 22

9 Critérios para Definição da Auto-Negociação ..................................................................... 23

10 Situação de perda do Cabo Profibus ................................................................................... 25

11 Situação de perda da Fibra Óptica ...................................................................................... 29

12 Situação de perda do Cabo Ethernet................................................................................... 30

13 Situação de perda do cabo Modbus RTU ............................................................................ 32

14 Motivos que levam o Sistema à Switchover ........................................................................ 33

15 Motivos que levam o Sistema à Desqualificação ................................................................ 35

16 Característica do Ciclo de Scan ............................................................................................ 36

16.1 Comportamento do ciclo de “Scan” em operação. ........................................... 36

16.2 Comportamento do ciclo de “Scan” no momento do Switchover. ................... 37

17 Características Fibra Óptica ................................................................................................. 38

18 Leds Indicadores .................................................................................................................. 40


19 Configuração Modbus TCP/IP Cliente ................................................................................. 41

19.1 CPUs utilizando diferentes endereços IP ........................................................... 41

19.2 CPUs utilizando mesmos endereços IP .............................................................. 44

20 Configuração Sistemas Supervisórios .................................................................................. 45

21 Realizando UpLoad e Download no Sistema Redundante .................................................. 47

21.1 Download de Memórias e TAGs, Ladder, Modbus RTU e Modbus/TCP ........... 48

21.2 Download em Módulos Profibus ....................................................................... 48

21.3 Sincronização de configurações diferentes ....................................................... 50

22 Diagnósticos de Erros e Eventos do Sistema Redundante .................................................. 51

23 Restrições ............................................................................................................................ 52

24 Informações Adicionais ....................................................................................................... 53

25 Perguntas e respostas freqüentes (FAQS) ........................................................................... 54

26 Glossário .............................................................................................................................. 56

27 Conclusões Finais ................................................................................................................. 58


Índice de tabelas

Tabela 14.1 – Ação e Reação do Sistema quando há falhas depois de Sincronizada ................. 34

Tabela 14.2 – Ação e Reação do Sistema quando há falhas na Energização .............................. 34

Tabela 16.1 – Tempo Máximo de Resposta no Switchover ........................................................ 37

Tabela 18.1 – Leds Indicadores da CPU ....................................................................................... 40

Tabela 26.1 – Glossário ............................................................................................................... 57


Índice de figuras

Figura 3.1 – Definição de Tolerante a Falhas e Falha Segura ........................................................ 8

Figura 4.1 – Componentes do Sistema Redundante ..................................................................... 9

Figura 4.2 – Exemplo de Arquitetura Sistema Redundante Citrino ............................................ 10

Figura 5.1 – Topologia de Rede Profibus – Exemplo 01 .............................................................. 12





Figura 6.1 – Configuração dos Módulos Mestres Profibus ......................................................... 16

Figura 6.2 – Configuração dos Parâmetros do Sistema Redundante .......................................... 17

Figura 8.1 – Comportamento do IPs no momento do Switchover ............................................. 21

Figura 8.2 – Comando Switchover pelo Citrino Tools ................................................................. 22

Figura 9.1 – Fluxograma de Definição da Auto-negociação ........................................................ 24

Figura 10.1 – Perda do Cabo Profibus – Exemplo 01 .................................................................. 26

Figura 10.2 – Perda do Cabo Profibus – Exemplo 02 .................................................................. 27

Figura 12.1 – Perda do Cabo Ethernet – Exemplo Um Único Switch .......................................... 30

Figura 12.2 – Perda do Cabo Ethernet – Exemplo Vários Switchs .............................................. 31

Figura 16.1 – Característica do Ciclo de Scan com Crossload ..................................................... 36

Figura 17.1 – Cabo de Fibra Óptica de 2 metros ......................................................................... 38

Figura 17.2 – Cabo de Fibra Óptica maior que 2 metros com conectores SC/SC ....................... 39

Figura 19.1 – Comunicação entre CPUs Redundantes com IPs Diferentes ................................. 41

Figura 19.2 – Comunicação entre CPU Redundante e Não Redundante com IPs Diferentes ..... 41

Figura 19.3 – Configuração de Conexões entre CPU Ativa e CPU Standby ................................. 42

Figura 19.4 – Configuração Trigger, Leitura e Escrita Modbus TCP – CPU Ativa ......................... 43

Figura 19.5 – Configuração Trigger, Leitura e Escrita Modbus TCP – CPU Standby .................... 43

Figura 19.6 – Comunicação entre CPUs Redundantes com IPs Iguais ........................................ 44

Figura 19.7 – Comunicação entre CPU Redundante e CPU Não Redundante com IPs Iguais ..... 44

Figura 20.1 – Topologia do Sistema de Supervisão utilizando OPC ............................................ 45

Figura 21.1 – Pesquisa por CPUs Disponíveis .............................................................................. 47

Figura 21.2 – Download Memórias e Tags, Ladder, Modbus-RTU e Modbus-TCP ..................... 48

Figura 21.3 – Download em Módulos Profibus ........................................................................... 48

Figura 21.4 – Configuração do Download sem Parada em Módulos Profibus ............................ 49

Figura 21.5 – Sincronização de Configuração entre CPUs........................................................... 50

Figura 21.6 – Confirmação de Sincronização entre CPUs ........................................................... 50

Figura 22.1 – Diagnóstico de Erros e Eventos do Sistema Redundante ...................................... 51


1 Prefácio

Esta publicação é destinada para uso de engenheiros e técnicos de automação os

quais são responsáveis por planejar e implementar as aplicações do Sistema Redundante com

PLC Citrino.

Este manual tem como objetivo prover informações específicas sobre o Sistema de

Automação Redundante utilizando o PLC Citrino, logo, as informações contidas neste manual

abrangem única e exclusivamente os tópicos relacionados ao Sistema Redundante, com suas

características, aplicações, detalhes de configurações e todas as informações que permitam

aos integradores de sistemas utilizarem este produto de forma prática e segura.

Porém, esta publicação não descarta a necessidade de leitura dos demais manuais do

produto, que contém informações sobre as características gerais do produto, como

informações de hardware, cartões de entradas e saídas, módulos de comunicação, protocolo

Modbus TCP/IP, protocolo Profibus, entre outras, e também a leitura do manual de

configuração do “Citrino Tools” que é a ferramenta de configuração do PLC Citrino.

É recomendada a leitura do item Glossário que se encontra ao final deste manual,

para entendimento de terminologia utilizada neste manual, facilitando assim sua total

compreensão.


2 Apresentação do Sistema Redundante

A proposta de usar um sistema de automação redundante é de reduzir os tempos de

parada de produção, independente de falhas que possam ocorrer por algum problema em

equipamentos ou até mesmo devido a problemas de manutenção, com isso, reduzir os custos

dessas paradas indevidas da produção.

O sistema Redundante utilizando o PLC Citrino consiste basicamente na composição

de dois conjuntos de “hardware” idênticos, que trabalham sincronizados entre si, e quando

por algum motivo um dos componentes de qualquer desses sistemas apresenta algum tipo de

falha, o conjunto redundante manterá o sistema operando sem que haja uma parada

inesperada de operação.


3 Definições do Sistema de Automação Redundante

Os sistemas de automação redundante são usados na prática com o objetivo de

alcançar um alto grau de disponibilidade e confiabilidade, e existem algumas diferenças entre

sistemas redundantes e sistemas de segurança, como segue:

ICS – Industrial Control Systems SIS - Safety Instrumented Systems

(Sistemas de Controle Industriais) (Sistemas de Controle Instrumentados)

Figura 3.1 – Definição de Tolerante a Falhas e Falha Segura

O Sistema de automação redundante utilizando PLC Citrino visa atender a um

sistema “Tolerante a Falhas” com a possibilidade de arquiteturas que contribuam diretamente

para maior disponibilidade e confiabilidade do processo industrial, as quais foram descritas em

detalhes nos próximos tópicos.

Sistemas de Automação Redundante

“Fault-tolerant” Tolerante a Falhas

Se qualquer elemento do sistema

apresentar falha, todo o conjunto é desativado e o sistema Standby assume

o controle, mantendo a operação do sistema sem interrupção.

Objetivo: reduzir risco de perda de produção por meio de operação em

paralelo de dois sistemas, tolerando a falha de 1 dos 2 sistemas.

“Fail-Safe” A Prova de Falhas ou Falha Segura

Um dispositivo de falha segura é aquele

que em caso de falha, responde de forma que não irá provocar nenhum

dano a outros dispositivos, pessoas ou ao ambiente.

Objetivo: Proteger a vida, o ambiente e os investimentos de maneira a colocar o

sistema em estado de segurança imediato como resultado de um

desligamento.


4 Características de Arquiteturas do Sistema Redundante

Toda arquitetura proposta como Sistema Redundante utilizando o PLC Citrino,

obrigatoriamente deverá consistir em dois conjuntos idênticos de equipamentos no nível de

controle, ou seja, se o sistema primário possui 1 Fonte, 1 CPU, 1 Módulo Profibus, o sistema

secundário deverá possuir os mesmos equipamentos tanto em quantidade quando em versões

de firmware idênticas.

Existe a possibilidade de até 4 (quatro) módulos MFI-PBM2 (mestre Profibus) para

cada CPU.

`

Figura 4.1 – Componentes do Sistema Redundante

A seguir apresenta-se uma arquitetura do sistema redundante utilizando Citrino,

abrangendo desde os elementos de campo no nível de controle até a comunicação com

sistemas supervisórios no nível de supervisão.

MPS1-RED

Fonte

MCPU-2

CPU

Redundante

MFI-PBM2

Módulo

Profibus

Mestre

MPS1-RED

Fonte

MCPU-2

CPU

Redundante

MFI-PBM2

Módulo

Profibus

Mestre

Fibra Óptica

Profibus

Sistema Redundante Primário Sistema Redundante Secundário


Figura 4.2 – Exemplo de Arquitetura Sistema Redundante Citrino

No exemplo apresentado acima, pode-se observar algumas características como

segue:

Elementos de Campo:

Posicionadores, Sensores,

Transmissores, Motores, etc.

Sistema Redundante

Primário

Sistema Redundante Secundário


Sistema de Supervisão: conectados ao sistema redundante Citrino por meio de

servidores OPC Redundante. Esta seria a topologia ideal, porém existe a possibilidade de

trabalhar apenas com um servidor OPC não redundante, e ainda a possibilidade de operar

diretamente com Modbus TCP/IP com conexões individuais para cada supervisório, sem a

necessidade de Servidor ou Cliente OPC. Para detalhamento consulte o item 20 - Configuração

Sistemas Supervisórios.

Fibra Óptica: a comunicação em fibra óptica entre os dois sistemas permite a troca

de informações entre as duas CPUs, o que mantém os sistemas sincronizados a cada ciclo de

execução do programa. Para detalhamento sobre tipo de fibra e distâncias permitidas,

consulte o item 17 - Características Fibra Óptica.

Sistema Redundante: na arquitetura exemplo apresentada, utilizou-se somente um

MFI-PBM (mestre Profibus) em cada um dos sistemas, por conseqüência uma única rede

Profibus representada com apenas uma remota com MFI-PBS (Escravo Profibus). Porém existe

a possibilidade de até 4 (quatro) cartões mestre Profibus e para cada CPU, e a possibilidade de

até 126 estações para cada mestre Profibus.

Topologia Rede Profibus: existe a possibilidade de diversas topologias de rede em

Profibus, desde uma simples topologia em linha como mostrada no exemplo anterior, até

aplicações com anel redundante. Para detalhamento das topologias de rede Profibus consulte

o item 5- Topologias de Rede Profibus permitidas e não permitidas.


5 Topologias de Rede Profibus permitidas e não permitidas

São várias as topologias permitidas para a rede Profibus, porém quando se trata de

sistema redundante, devem-se tomar alguns cuidados na escolha da topologia com o objetivo

de agregar maior disponibilidade quando ocorrer algum problema com o cabo Profibus.

Serão representadas a seguir algumas topologias de rede, sempre com a

demonstração de 3 (três) estações Profibus representados como remotas (escravos) pelo MFI-

PBS, mas poderiam ser qualquer outro tipo de equipamento escravo Profibus DP.

Exemplo 01: A utilização de módulos de entradas e saídas, como: Entradas

Analógicas, Saídas Analógicas, Entradas Digitais, Saídas Digitais, Entradas de Freqüência, etc.

não são permitidas diretamente no mesmo segmento da CPU, isto se deve, porque toda a

redundância do Citrino é baseada nos módulos mestres Profibus, logo, todos os módulos

citados acima devem ser utilizados como uma remota Profibus, como será apresentado nos

exemplos seqüentes.

Figura 5.1 – Topologia de Rede Profibus – Exemplo 01

Exemplo 02: Topologia em linha, com remotas após os sistemas redundantes de

controle. Nesta topologia o trecho 02 se torna crítico, por ser o único caminho até as remotas

de campo. Caso haja um rompimento no cabo neste trecho 02, haverá perda de comunicação

todas as remotas.

M16AI M16AO M32DI M32DO M16AI M16AO M32DI M32DO

Topologia não Permitida



Exemplo 03: Topologia em anel não permitida, porque com o cabo Profibus

obrigatoriamente deverá ter os terminadores, logo o trecho 05, por exemplo, não poderá

existir. Caso haja opção por escolher uma topologia em anel redundante, deverá ser seguida a

topologia apresentada no exemplo 04.


Topologia não Permitida


Exemplo 04: Topologia em anel utilizando fibra óptica, que permite quando houver

um rompimento da fibra em qualquer ponto, o sistema continuar comunicando normalmente

devido à característica dos equipamentos conversores de Profibus para fibra óptica

redundante. Esta topologia está certamente entre as que garantem maior disponibilidade ao

sistema, porém com custos possivelmente mais elevados para sua implementação.


Exemplo 05: Topologia em linha, com remotas entre os sistemas redundantes de

controle. Topologia ideal quando não utilizado fibra óptica em anel, porque garante alta

disponibilidade mesmo quando há rompimento em algum dos trechos intermediários.



Há um detalhamento do comportamento do sistema redundante quando há perda

do cabo Profibus (rompimento ou desconexão) no item 10 - Situação de perda do Cabo

Profibus, que certamente complementará o entendimento apresentado neste tópico e

contribuirá para melhor escolha da topologia a ser utilizada em sua planta industrial.

Topologia Ideal Sugerida


6 Configuração da Redundância com Citrino Tools

6.1 Configuração dos Módulos Mestres Profibus

Os módulos mestres Profibus deverão ser configurados através da ferramenta

“Citrino Tools”, na qual serão adicionados todos os escravos, como o exemplo mostrado na

figura abaixo.

Figura 6.1 – Configuração dos Módulos Mestres Profibus

Nota: Qualquer informação adicional sobre detalhes de configuração do mestre

Profibus, consultar o manual do software “Citrino Tools”.

Observe que na configuração dos módulos Profibus, não há nenhuma mudança

adicional a ser realizada devido ao sistema redundante, para o configurador o procedimento é

exatamente idêntico a configuração quando o sistema não é redundante.

A atenção maior fica por conta do endereçamento dos módulos mestres Profibus,

como apresentado na seqüência.

• Endereçamento do Profibus

O endereçamento no mestre Profibus deverá estar entre 1 (um) e 125 (cento e vinte

e cinco), não podendo ser “0” (zero), e também o endereço imediatamente inferior deverá


ficar livre, porque quando o sistema está em sincronismo, o módulo Profibus Ativo terá o

endereço atribuído no momento da configuração, e o módulo Profibus Standby terá o

endereço subtraído de 1 (um).

Por exemplo, se o módulo Profibus foi configurado com endereço “1” (um), o módulo

ativo permanecerá “1” (um) e o módulo Standby será “0” (zero).

6.2 Configuração dos Parâmetros do Sistema Redundante

Alguns parâmetros podem ser configurados através do “Citrino Tools” na opção

Ferramentas � Redundância � Configurar Redundância, de maneira a atender as melhores

necessidades de cada aplicação.

Figura 6.2 – Configuração dos Parâmetros do Sistema Redundante


A seguir o detalhamento de cada item desta janela de configuração:

• Habilitação do sistema redundante

Esta opção deve ser selecionada quando de fato o sistema irá trabalhar como

redundante. Caso haja necessidade de utilizar a CPU em modo não redundante, esta opção

deverá ser desmarcada.

• Efetuar Switchover por falha na Ethernet ?

A opção de realizar Switchover quando há desconexão ou rompimento do cabo

ethernet na CPU Ativa é importante ser configurada como “SIM”, porque apesar da leitura

estar disponível na CPU Standby, qualquer escrita na mesma será reescrita pela CPU Ativa, o

que inibiria qualquer comando de escrita do supervisório.

Esta opção poderá ser configurada como “Não” somente quando não há utilização de

sistema supervisório, o em alguma aplicação específica que exija esta opção.

• Definição das configurações da Ethernet

Nas configurações do sistema redundante, é possível optar em utilizar o mesmo

endereço IP para ambas as CPUs ou utilizar endereços IPs diferentes.

Quando configurada para utilizar o mesmo endereço IP, a CPU que tiver em modo

Standby terá o IP subtraído de 1 (um), por exemplo, CPU configurada com IP 192.168.1.100, o

sistema que estiver em modo Standby, a CPU terá o IP 192.168.1.99. Logo é necessário que os

dígitos finais da classe de IP não sejam menores que 2 (dois).

Exemplo: 192.168.1.xxx

Deverá ser maior ou igual a 2 (dois).

Quando configurada para utilizar IPs diferentes em cada CPU, os endereços de IPs

poderão ser quaisquer, até mesmo em classes e subclasses diferentes, porém no momento do

Switchover não ocorrerá à troca do IP entre as CPUs.

Nota: Para maiores informações sobre o comportamento da Ethernet no momento

do Switchover, consulte o item 12 - Situação de perda do Cabo Ethernet.


• Definição dos tempos limites e reenvio

Todo protocolo de comunicação consiste em levar informações de um ponto a outro

com a maior confiabilidade possível. Um dos detalhes previstos em comunicação é a

possibilidade de um determinado pacote que foi enviado não ser entregue por seu receptor, e

quando isso acontece alguns procedimentos podem ser tomados na tentativa de reenviar o

mesmo pacote. Diante disso os parâmetros previstos neste item referem-se exatamente a esta

situação, que são as definições de tempos para reenvio dos pacotes e quantidade de tentativas

(reenvio) que poderão ser realizadas para restabelecer a comunicação.

Segue abaixo as definições de cada um dos parâmetros referentes aos tempos limites

de reenvio:

• TMO_ACT: Intervalo de tempo para reenvio da CPU Ativa, quando não houve

resposta. Ou seja, a CPU Ativa enviou algum pacote de dados para a CPU Standby,

e caso a mesma não responda em TMO_ACT (50ms 1000ms), a CPU Ativa irá

realizar um novo reenvio.

• QTD_RET: É o parâmetro que define a quantidade de reenvios máximos

permitidos. Se após todas as tentativas estabelecidas no parâmetro QTD_RET (1 a

10) não forem respondidas com sucesso, a CPU Ativa irá considerar a CPU Standby

como não sincronizada.

• TMO_SBY: este parâmetro é praticamente o inverso do TMO_ACT, ou seja, é o

intervalo de tempo que a CPU Standby não recebe nenhum pacote da CPU Ativa.

Isso pode ocorrer quando há desconexão ou rompimento da fibra óptica entre

elas, e a CPU Standby tomará ações pertinentes para verificação.

Este parâmetro deve ser TMO_ACT x QTD_RET.

Exemplo: TMO_ACT = 5 (50ms)

QTD_RET = 2 (reenvios)

TMO_SBY = 5 x 2 = 10 (100ms)


7 Inicialização e Operação do Sistema Redundante

Quando o sistema redundante é iniciado, a CPU irá verificar se todos os módulos

estão funcionando corretamente e se as versões de firmware estão corretas para funcionar o

sistema redundante. Caso não haja nenhuma falha nos módulos, o sistema se tornará

qualificado. Caso contrário o mesmo se tornará desqualificado e não dará seqüência na auto-

negociação.

Uma vez o sistema qualificado, o mesmo iniciará o processo de auto-negociação

enviando comandos pela fibra óptica buscando seu par redundante, para resolver se irá

funcionar como ativo ou como standby.

Caso haja recebimento de resposta, haverá a auto-negociação definindo então o

estado atual da CPU. Na seqüência a CPU em modo ativa irá iniciar o processo de sincronização

através da realização do “Crossload” entre as CPUs o que será feito a todo ciclo de “scan”

mantendo-as sincronizadas.

No momento da auto-negociação, a CPU poderá ficar até 10 (dez) segundos enviando

mensagens, e caso nunca receba uma resposta, a mesma se tornará ativa permitindo a

operação do sistema, porém sem que haja redundância neste momento.

Esta situação pode ocorrer caso um dos sistemas não tenha sido iniciado ao mesmo

tempo. Mas caso este seja iniciado em qualquer outro momento, a auto-negociação ocorrerá e

também a sincronização entre as duas CPUs sem que haja qualquer parada no processo.

Ou seja, é possível iniciar um sistema independente do outro, e a qualquer momento

posterior realizar a sincronização entre ambos, sem que haja qualquer interferência no

processo.


8 Comportamento do Sistema no momento do Switchover

8.1 Comportamento dos IPS no momento do Switchover

No momento do Switchover entre as CPUs, ocorrerá a inversão dos endereços de IPs

entre as mesmas. Ou seja, CPU Standby ficará com o IP da CPU Ativa e vice-versa.

Figura 8.1 – Comportamento do IPs no momento do Switchover

Como apresentado no item 6.2 - Configuração dos Parâmetros do Sistema

Redundante, é possível não realizar a inversão dos IPs no momento do Switchover, porém esta

opção padrão é altamente recomendável. Para maiores detalhes consulte o item referido.

Inversão dos IPs no Switchover


8.2 Comando de Switchover pelo Citrino Tools

A realização do Switchover entre as CPUs pelo “Citrino Tools” é uma opção existente

e que somente fica disponível quando as duas CPUs estão sincronizadas.

Importante lembrar que no momento do Switchover a CPU Standby se tornará Ativa,

e a CPU que operava em modo ativa ficará desqualificada por cerca de 10 segundos até que

ocorra novamente a sincronização entre elas.

Figura 8.2 – Comando Switchover pelo Citrino Tools

8.3 Comando de Switchover pelo Sistema de Supervisão ou Lógica Ladder

Também é possível a realização do Switchover através de sistemas supervisórios ou

até mesmo de lógica ladder.

A variável ST 256 (variável de sistema), tamanho 16 bits, é a responsável por receber

o comando Switchover tanto por sistemas de supervisão quanto pela própria lógica ladder.

Caso haja uma escrita no valor de “0xD53B” (Hexadecimal) na variável ST 34, e o

sistema esteja operando de forma sincronizada entre as duas CPUs, ocorrerá o Switchover

instantaneamente, e automaticamente este valor de escrita será retornado para x0000

(Hexadecimal).


9 Critérios para Definição da Auto-Negociação

Os critérios da auto-negociação, se valem somente quando os dois sistemas estão em

energização praticamente simultânea, sendo essa diferença de energização menor que 10

(dez) segundos, pois caso um dos sistemas já tenha iniciado anteriormente e esteja operando

como ativo, o sistema que iniciar após automaticamente ficará em modo Standby

independente de qualquer configuração previamente realizada.

Porém quando os dois sistemas iniciam simultaneamente (intervalo menor que 10

segundos) ambas as CPUs irão trocar informações sobre auto-negociação e respeitarão os

seguintes critérios, como segue:


Figura 9.1 – Fluxograma de Definição da Auto-negociação


10 Situação de perda do Cabo Profibus

Sempre que há perda do cabo Profibus, seja por desconexão ou por rompimento do

cabo, o sistema redundante identifica a falha, e esta falha pode ou não levar o sistema a

realizar o Switchover.

Esta situação se deve, porque a perda do cabo Profibus pode ocorrer em qualquer

ponto da rede, e dependendo do ponto onde houve a desconexão ou rompimento o sistema

tomará ações diferentes, mas sempre buscando a melhor maneira de manter o sistema

operando.

Quando há uma perda do cabo de maneira que o módulo Profibus ativo não consiga

trocar informações com o módulo Profibus Standby, ocorrerá uma verificação se o módulo

Profibus ativo consegue se comunicar com 50% ou mais dos escravos, caso isso ocorra, não

haverá Switchover, caso contrário, o Switchover ocorrerá.

Uma informação importante da característica do sistema é a seguinte:

• Módulo Profibus em modo Ativo: enxerga todos os escravos na linha Profibus, mas não

faz distinção entre estar ou não comunicando com o módulo Profibus Standby.

• Módulo Profibus em modo Standby: não enxerga nenhum escravo na linha, só enxerga

o módulo Profibus ativo.

Com essas informações podemos afirmar que para o módulo Profibus ativo, não

importa se o módulo Profibus Standby não estiver comunicando, o que importa é a

comunicação com os escravos.

Por outro lado para o módulo Profibus Standby, o que importa é comunicar com o

módulo Profibus Ativo, não importando a comunicação com os escravos, a menos que se torne

ativo.

Os exemplos a seguir tonarão mais claras essas situações.


• Exemplo Topologia 01

Figura 10.1 – Perda do Cabo Profibus – Exemplo 01

Situações propostas:

Perda cabo no trecho 01 � O módulo Profibus ativo perderá comunicação com todos os

escravos e enviará comando Switchover para CPU Standby

assumir o controle.

Perda cabo no trecho 06 � Ocorrerá Switchover, porém tanto o módulo Profibus ativo

quando Standby perderam comunicação com os escravos.

Perda cabo nos trechos

02, 03, 04 ou 05 � Os escravos a partir do ponto interrompido perderão

comunicação com ambos os mestres Profibus, e não haverá

Switchover, porque ainda existe comunicação entre os módulos

mestres Profibus e há pelo menos 1 escravo funcionando.

Como se pode observar a arquitetura apresentada acima, qualquer problema que

ocorrer no trecho 06 interromperá o funcionamento desta rede Profibus, logo o ideal é que os

escravos estejam alocados fisicamente entre os dois controladores, como apresentado na

topologia a seguir.

MPS1-

RED

Fonte

CPU em Modo Ativa CPU em Modo Standby

MCPU-

2-RED

CPU

MFI-

PBM2

Profibus

Mestre

MPS1-

RED

Fonte

MCPU-

2-RED

CPU

MFI-

PBM2

Profibus

Mestre

Escravo

01

Escravo

02

Escravo

03

Escravo

04

Escravo

05

01

02 03 04 05 06

T

T


• Exemplo Topologia 02

Figura 10.2 – Perda do Cabo Profibus – Exemplo 02

Situações propostas:


01, 02 ou 03 � Com a perda do cabo nesses trechos, ocorrerá à falta de

comunicação entre os dois mestres, e por conseqüência como

o módulo Profibus ativo está conseguindo comunicar com

menos de 50% dos escravos, ocorrerá Switchover, a CPU

Standby assumirá o controle, e a maioria dos escravos

continuarão comunicando, sendo que, se a falha for:

• No trecho 01: Todos os escravos continuarão funcionando

• No trecho 02: Somente o escravo 01 perderá comunicação

• No trecho 03: Os escravos 01 e 02 perderão comunicação


04, 05 ou 06 � Com a perda do cabo nesses trechos, ocorrerá à falta de

comunicação entre os dois mestres, porém como o módulo

Profibus ativo está conseguindo comunicar com 50% ou mais

dos escravos, não ocorrerá Switchover, e o sistema continuará

MPS1-

RED

Fonte

CPU em Modo Ativa CPU em Modo Standby

MCPU-

2-RED

CPU

MFI-

PBM2

Profibus

Mestre

MPS1-

RED

Fonte

MCPU-

2-RED

CPU

MFI-

PBM2

Profibus

Mestre

Escravo

01

Escravo

02

Escravo

03

Escravo

04

Escravo

05

01 02 03 04 05 06

T T


operando pela mesma CPU, e a maioria dos escravos

continuarão comunicando, sendo que, se a falha for:

• No trecho 06: Todos os escravos continuarão funcionando

• No trecho 05: Somente o escravo 05 perderá comunicação

• No trecho 04: Os escravos 04 e 05 perderão comunicação

Como se pode observar a arquitetura apresentada acima permitiu maior flexibilidade

ao sistema redundante, dando assim maior disponibilidade ao sistema, porque em nenhum

momento ocorreu parada total da rede. Logo é importante em cada aplicação a verificação de

qual a melhor topologia a ser utilizada garantindo assim o melhor aproveitamento do sistema

redundante disponível.

As arquiteturas apresentadas acima foram apenas duas ilustrações das situações de

perda do cabo Profibus e o comportamento do sistema redundante em cada situação. É claro

que outras arquiteturas serão aceitas na prática, conforme mostrado no item 5 - Topologias de

Rede Profibus permitidas, porém todas as considerações realizadas neste tópico servirão de

base para análise da topologia escolhida em sua indústria.


11 Situação de perda da Fibra Óptica

Quando há perda da comunicação via fibra óptica, seja por desconexão ou por

rompimento da fibra, ocorrerá instantaneamente a dessincronização do sistema redundante, o

qual continuará operando pela CPU que estava Ativa.

A CPU que operava em modo Standby entrará em modo Desqualificada e ficará a

todo tempo tentando uma auto-negociação com a CPU Ativa, o que ocorrerá quando o enlace

de fibra óptica for restabelecido entre as duas CPUs.

Vale lembrar que, enquanto se mantiver a desconexão ou rompimento da fibra, o

sistema continua operando normalmente, porém não há sincronismo, logo, qualquer falha que

venha ocorrer durante este período no sistema Ativo, conseqüentemente poderá levar a

parada do módulo onde ocorreu a falha.


12 Situação de perda do Cabo Ethernet

A situação de perda do cabo ethernet acarreta em uma possível perda de

comunicação com sistemas supervisórios e também de comunicação entre CPUs via Modbus

TCP/IP. Devido a isso, a perda do cabo ethernet é configurada como padrão para ocasionar o

Switchover.

Porém a CPU consegue detectar a perda do sinal somente no trecho entre a CPU e o

switch mais próximo. Não há como saber, caso a topologia de rede utilize vários switchs, se

houve uma falha em algum ponto posterior ao primeiro switch, ou seja, a CPU considera:

• Existência de sinal � Considera a rede ethernet como correta

• Não existência de sinal � Considera a rede ethernet com enlace perdido

Veja os exemplos a seguir:

• Um único Switch

Figura 12.1 – Perda do Cabo Ethernet – Exemplo Um Único Switch

- Ocorrerá Switchover

- Ethernet Perda Link

- Estado Desqualificada

- Estado Dessincronizada





• Vários Switchs

Figura 12.2 – Perda do Cabo Ethernet – Exemplo Vários Switchs

- Ocorrerá Switchover







- Não Ocorrerá Switchover

- Não detecção perda Link

- Qualificada e Sincronizada

- Perde comunicação IHM

- Não Ocorrerá Switchover

- Não detecção perda Link

- Qualificada e Sincronizada

- Perde comunicação IHM


13 Situação de perda do cabo Modbus RTU

A situação de perda do cabo Modbus RTU pode ser configurada como um motivo que

leva a CPU a realizar Switchover. Porém a rede Modbus RTU em sua topologia não permite a

comunicação entre os mestres Modbus e também a velocidade da rede é baixa com relação a

outros tipos de protocolos.

Logo, a orientação é que, em um sistema redundante, esta rede seja utilizada

somente para monitoração de informações, mas não para controle porque a detecção de falha

ou desconexão do cabo Modbus-RTU pode levar até 5 (cinco) segundos. Somente após esse

tempo é que a CPU Ativa toma a decisão de realizar um Switchover.

Importante entender que, devido à característica do protocolo Modbus-RTU,

somente será realizado um Switchover se o mestre Ativo não conseguir comunicar com

nenhum escravo, ou seja, pode até ter ocorrido algum rompimento ou desconexão do cabo,

mas dependendo da topologia aplicada e do ponto onde aconteceu a falha, isso ficará

transparente para o sistema caso o mestre esteja comunicando com pelo menos 1 (um)

escravo, e assim não realizará Switchover.

A configuração que define se a perda do cabo Modbus-RTU é motivo de Switchover

ou não, pode ser realizada na aba Ferramentas � Redundância � Configurar Redundância.


14 Motivos que levam o Sistema à Switchover

Quanto uma falha ocorre em qualquer dos componentes da CPU Ativa,

automaticamente o Switchover ocorrerá e a CPU que estava em modo Standby irá se tornar

ativa e assumir o controle do processo, sem que haja interrupção do sistema. Apresentam-se

abaixo os motivos que levam a CPU realizar Switchover.

• Qualquer das seguintes falhas nos componentes do Sistema Ativo:

o Queda fonte de alimentação

o Falha ou retirada na CPU

o Falha ou retirada de qualquer módulo do sistema ativo

o Rompimento ou desconexão do cabo Profibus (verificar detalhes no item 10 -

Situação de perda do Cabo Profibus)

o Rompimento ou desconexão do cabo ethernet (verificar detalhes no item 12 -

Situação de perda do Cabo Ethernet)

o Rompimento ou desconexão do cabo Modbus RTU (verificar detalhes no item 13 -

Situação de perda do cabo Modbus RTU)

• Comando enviado pelo Citrino Tools por escolha do usuário

• Comando enviado pelo Supervisório, com escrita de valor específico no endereço de

“Comando Switchover”

Obs.: as mesmas falhas apresentadas nos itens acima, quando ocorridas nos

componentes do Sistema Standby, automaticamente irão torná-lo desqualificado, e neste

momento o sistema ficará dessincronizado, até que o problema seja resolvido. Uma vez

resolvidos os problemas e não havendo mais motivos que mantenham o Sistema em modo

desqualificado, automaticamente haverá uma nova auto-negociação e ocorrerá então a re-

sincronização entre os dois conjuntos que compõem o sistema redundante.

A tabela a seguir representa uma co-relação entre as causas e efeitos de cada

componente, esclarecendo a reação do sistema para cada possibilidade de falha.


• Situações apresentadas quando o sistema está operando de forma sincronizada.

O que acontece quando ocorre ... ? Qual a reação do sistema ?

Desligamento de todo o sistema Ativo Ocorrerá Switchover e o sistema Standby se tornará Ativo

Desligamento de todo o sistema Standby O Sistema Ativo continuará operando normalmente, mas ocorrerá o dessincronismo

Retirada ou falha na CPU Ativa Ocorrerá Switchover e o sistema Standby se tornará Ativo

Retirada ou falha na CPU Standby O Sistema Ativo continuará operando normalmente, mas ocorrerá o dessincronismo

Retirada ou falha de qualquer módulo na CPU Ativa Ocorrerá Switchover e desqualificação do sistema que operava como Ativo, e o sistema Standby se tornará Ativo

Retirada ou falha de qualquer módulo na CPU Standby O Sistema Ativo continuará operando normalmente, mas ocorrerá o dessincronismo e a desqualificação do sistema Standby

Colocação da CPU Ativa em Stop Ambas as CPUs entrarão em STOP e ocorrerá parada total da operação do sistema

Colocação da CPU Standby em Stop A CPU Standby entrará em STOP e se tornará desqualificada, ocorrendo então o dessincronismo

Perda Fibra Óptica O Sistema Ativo continuará operando normalmente, e o Sistema Standby se tornará desqualificado

Desconexão ou rompimento do Cabo Profibus Poderá ou não ocorrer Switchover, dependendo do ponto onde ocorreu a rompimento do cabo, consultar item 10 - Situação de perda do Cabo Profibus

Desconexão ou rompimento do Cabo Ethernet Poderá ou não ocorrer Switchover, dependendo da configuração realizada, consultar item 12 - Situação de perda do Cabo Ethernet

Tabela 14.1 – Ação e Reação do Sistema quando há falhas depois de Sincronizada

• Situações apresentada no momento da energização (Power Up)

O que acontece quando energizo o sistema ... ? Qual a reação do sistema ?

Sem qualquer módulo ou com problema no mesmo O conjunto que está sem módulos ou com algum módulo em falha irá ficar desqualificado e não realizará a auto-negociação até que o problema seja resolvido

Sem conexão ou com rompimento do cabo Profibus

Se algum dos mestres estiver comunicando com algum escravo o sistema iniciará, porém dependo do ponto onde ocorreu o rompimento e da topologia de rede, um dos sistemas poderá ficar desqualificado.

Sem conexão ou com rompimento do cabo ethernet O sistema que não estiver com link de ethernet disponível ficará desqualificado

Sem conexão ou com rompimento da fibra óptica Após 10 segundos as duas CPUs tentarão se tornar ativa, mas somente uma delas permanecerá e a outra se tornará desqualificada.

Com a CPU em Stop Esta CPU ficará aguardando ser colocada em modo RUN para iniciar a auto-negociação

Tabela 14.2 – Ação e Reação do Sistema quando há falhas na Energização


15 Motivos que levam o Sistema à Desqualificação

O princípio de desqualificação do sistema ocorre quando há uma falha em qualquer

dos componentes do sistema que o impeçam de funcionar corretamente. Uma vez o sistema

estando desqualificado não haverá sincronismo entre as CPUs até que a falha seja resolvida.

Seguem abaixo alguns motivos que levam o Sistema à desqualificação:

• Qualquer das seguintes falhas nos componentes tanto do Sistema Ativo quanto do

Sistema Standby:

o Queda fonte de alimentação

o Falha ou retirada na CPU

o Falha ou retirada de qualquer módulo do sistema ativo

o Rompimento ou desconexão do cabo Profibus (verificar detalhes no item 10 -

Situação de perda do Cabo Profibus)

o Rompimento ou desconexão do cabo ethernet (verificar detalhes no item 12 -

Situação de perda do Cabo Ethernet)

o Rompimento ou desconexão do cabo Modbus RTU (verificar detalhes no item 13

- Situação de perda do cabo Modbus RTU)

o Rompimento ou desconexão da fibra óptica

Lembrando que, quando a desqualificação ocorre na CPU Ativa, ocorrerá o

Switchover e a CPU Standby assumirá o controle tornando-se Ativa neste momento. Quando a

desqualificação ocorre na CPU Standby, não ocorrerá o Switchover, somente haverá a

dessincronização do sistema, e a CPU Ativa continuará no controle.


16 Característica do Ciclo de Scan

16.1 Comportamento do ciclo de “Scan” em operação.

O comportamento do Scan em um Sistema Redundante deve levar em consideração

que os dados precisam ser copiados para a CPU Standby a cada ciclo. A imagem a seguir ilustra

como este procedimento é realizado.

Leitura nos Módulos de Entrada na

CPU Ativa

Execução de Lógicas de Controle

na CPU Ativa

Execução Crossload entre CPU Ativa e

CPU Standby

Escrita nos Módulos de Saída na

CPU Ativa

tempo de sincronização

Figura 16.1 – Característica do Ciclo de Scan com Crossload

Como podemos ver na imagem acima, a todo ciclo de scan a CPU Ativa atualiza as

informações na CPU Standby através do crossload. O tempo de crossload pode variar de

acordo com o tamanho da configuração existente nas CPUs, sendo na ordem de alguns

milissegundos. Porém esta cópia é feita apenas nas regiões de memória onde aconteceram

alterações no momento da execução da lógica de controle, o que é chamado de crossload

parcial, e que garante que os dois sistemas se mantenham exatamente iguais, e ao mesmo

tempo reduz significativamente o tempo de realização do crossload.

Logo, em um sistema redundante, o tempo de scan é aumentado em alguns

milissegundos em função da sincronização entre os dois sistemas, porém esse tempo é baixo o

suficiente para não prejudicar em nada a operação do sistema.

Nota: A CPU Standby recebe a todo ciclo os dados da CPU Ativa, porém em modo

Standby ela não executa a rotina de lógicas de controle e também não escreve nos módulos de

saída.

Tempo do Ciclo de Scan


16.2 Comportamento do ciclo de “Scan” no momento do Switchover.

O evento de ocorrer uma falha em qualquer componente do sistema não está

condicionado há um tempo definido, ou seja, pode ocorrer a qualquer momento, e diante

disso, a falha pode ocorrer enquanto a CPU estava lendo os módulos de entrada, ou

executando as lógicas de controle, escrevendo nos módulos de saída, ou até mesmo qualquer

outra tarefa.

Independente do momento em que a falha ocorra, o Switchover entre os dois

sistemas irá ocorrer, e a CPU Standby assumirá o controle, iniciando o ciclo de scan desde o

início, com a leitura dos módulos de entrada até a escrita nos módulos de saída após a

execução da lógica de controle. Com isso, há a garantia de que nunca haja perda da

informação nem não pouco qualquer falha no processo, garantindo assim total disponibilidade

de operação do sistema.

Neste momento de Switchover o tempo de scan poderá estender por alguns

milissegundos dependendo de qual foi o motivo que levou a CPU a esta ação, devido às

verificações necessárias para a tomada de decisões corretas. A tabela abaixo demonstra os

tempos pertinentes a cada tipo de falha no sistema.

Motivo do Switchover Tempo máximo de Resposta

Desligamento ou queda de Energia da CPU < 10ms

Falha ou retirada da CPU < 300ms

Falha ou retirada de qualquer módulo do sistema ativo < 200ms

Rompimento ou desconexão do cabo Profibus < 200ms

Rompimento ou desconexão do cabo ethernet < 100ms

Rompimento ou desconexão do cabo Modbus RTU < 6 segundos

Tabela 16.1 – Tempo Máximo de Resposta no Switchover

Nota: Lembrando que tanto o rompimento ou desconexão dos cabos Profibus,

Modbus RTU ou Ethernet, não necessariamente levam a CPU a Switchover, isso depende de

alguns critérios já apresentados em itens anteriores em detalhes neste manual.


17 Características Fibra Óptica

Para realização do sincronismo entre as 2 (duas) CPUs que compõem o sistema

redundante, a troca de dados entre as mesmas é realizada por meio de Fibra Óptica.

A utilização de Fibra Óptica nos meios de comunicação se deve pela característica de

imunidade a ruídos, diferentemente dos cabos de cobre. As Fibras ópticas não exigem regras

rigorosas de aterramento para evitar interferências e também não precisam de resistores de

terminação para evitar reflexões.

Devido a essas características de imunidade a ruídos e também ao fato da Fibra

Óptica utilizar luz para transmissão de dados, consegue-se altas velocidades de transmissão de

informações e maior segurança na comunicação.

Logo, um dos componentes do Sistema

de Automação Redundante é o cabo de fibra

óptica, que para aplicações onde a distância

entre os conjuntos redundantes não seja

superior a 2 metros, poderá ser utilizado o cabo

de Fibra Óptica com as seguintes informações:

Figura 17.1 – Cabo de Fibra Óptica de 2 metros

Fabricante: Amphenol Fiber Optics

Produto: Cabo de Fibra Óptica Multimodo 62.5/125 µm, Conector SC/SC Duplex, Comprimento 2m

Referência Fabricante: EC137-24P4P-002

Modelo: CSCPC-CSCPC-M-2-2M

Para aplicações onde a distância entre os 2 (dois) conjuntos de CPUs seja superior a 2

(dois) metros, será necessária a customização do enlace de fibra óptica respeitando algumas

características de cabo e distância, como segue abaixo:


Figura 17.2 – Cabo de Fibra Óptica maior que 2 metros com conectores SC/SC

Tipo de Fibra: Cabo de Fibra Óptica Multimodo 62.5/125 µm (Fibra de Vidro)

Conector: Conector SC/SC Duplex para conexão ao Módulo MCPU-2

Comprimento: 2 a 1000 metros (1 KM)

Tipo Ementa: Os conectores deverão ser ementados por fusão.

Nota Importante: Este laço de fibra óptica deverá ser certificado com empresa

especializada neste tipo de aplicação, para garantia do enlace de comunicação entre os 2 (dois)

sistemas redundantes.


18 Leds Indicadores

Os leds indicadores fornecem informações rápidas para diagnósticos do estado atual

da MCPU-2, conforme detalhados abaixo:

Leds Descrição Indicações Situação Normal

PWD

(verde)

Power

(Energização do módulo)

Aceso: módulo energizado

Apagado: módulo desligado Aceso quando ligado

FAIL

(vermelho) Falha de Hardware ou reset

Piscando: reset em andamento

Apagado: situação normal Apagado

LOW BATT

(vermelho) Bateria Baixa

Aceso: bateria descarregada ou sem

bateria

Apagado: bateria normal

Apagado

STP

(vermelho)

Stop (Parada), não

executando ciclo de lógicas

Aceso: CPU em modo STOP

Apagado: CPU em modo RUN Apagado

MB Err

(vermelho) Erro no Modbus

Aceso: módulo com erro

Apagado: módulo sem erro Apagado

FB Err

(vermelho)

Erro de configuração,

parametrização,

comunicação e hardware

(número de piscadas indica

o erro, seguidas de intervalo

de 1 segundo)

1 Piscada – Módulo não parametrizado

2 Piscadas – Módulo não configurado

3 Piscadas – Módulo parametrizado

incorretamente

4 Piscadas – Módulo configurado

incorretamente

5 Piscadas – Mestre ausente ou não

comunicando com módulo

6 Piscadas – Erro de hardware

Apagado

STL Err

(vermelho)

Erro de STL, algum

problema com a compilação

da lógica STL ou Ladder

Aceso: lógica com erro

Apagado: lógica sem erro Apagado

FO Err

(vermelho) Erro na Fibra Óptica

Aceso: indica que não houve comunicação

entre as CPUs, sugerindo possível erro na

Fibra Óptica

Apagado

DIS

(vermelho) CPU Desqualificada

Aceso: CPU Desqualifica, quando há algum

módulo em falha ou cabo desconectado

Apagado: CPU Qualificada

Apagado

STDBY

(verde) CPU Modo Standby Aceso: CPU operando em Modo Standby

Qualquer situação é

normal, led apenas

indica o Status de

operação atual da CPU

ACT

(verde) CPU Modo Ativo Aceso: CPU operando em Modo Ativo

Qualquer situação é

normal, led apenas

indica o Status de

operação atual da CPU

SYNC

(verde) Erro Sincronismo CPUs

Apagado: CPUs sincronizadas entre si,

realizando troca de dados a todo ciclo

Piscando: CPUs dessincronizadas

Apagado, quando as

duas CPUs estão

sincronizadas

Tabela 18.1 – Leds Indicadores da CPU


19 Configuração Modbus TCP/IP Cliente

A configuração do Modbus TCP/IP pode ser realizada para trocar informações entre

CPUs Citrino, ou até mesmo com qualquer outro equipamento que comunique via protocolo

Modbus TCP/IP.

Vale lembrar que a troca de informações neste nível de comunicação não é sugerida

para realização de malhas de controle, mas sim, para informações de monitoração ou inter-

travamentos lógicos.

Serão apresentadas a seguir, algumas características que precisam ser observadas

para a configuração do Modbus TCP/IP quando se trata de um sistema redundante.

19.1 CPUs utilizando diferentes endereços IP

Nesta situação em que as CPUs utilizam diferentes IPs, sabe-se que no momento do

Switchover, não haverá a troca dos IPs entre as CPUs. Ou seja, o endereço de IP não está

relacionado com o status de Ativa ou Standby da CPU. Os exemplos abaixo mostram

comunicação entre CPUs redundantes e também comunicação entre CPU Redundante com

CPU Não Redundante.

Figura 19.1 – Comunicação entre CPUs Redundantes com IPs

Diferentes Figura 19.2 – Comunicação entre CPU Redundante e Não

Redundante com IPs Diferentes


Em ambos os casos, especificamente quando a ethernet está configurada para operar

com IPs diferentes nas duas CPUs, será necessária a criação de duas conexões, ou seja, uma

conexão para a CPU Ativa e outra para CPU Standby, porque quando ocorrer o Switchover não

haverá inversão dos endereços de IP.

Logo, na aba Modbus/TCP do “Citrino Tools” deve-se criar uma conexão com a CPU

Primária e outra com a CPU Secundária, como mostra a figura a seguir:

Figura 19.3 – Configuração de Conexões entre CPU Ativa e CPU Standby

Como neste caso não há uma relação direta entre CPU Ativa e IP, ou seja, qualquer

das duas CPUs quando estiverem operando quando ativa mantém os seus próprios IP, será

necessário criar uma condição de “Trigger” (evento de disparo) que quando verdadeira

executa a leitura ou escrita das variáveis desejadas.

É criada uma primeira leitura que sempre monitora a variável ST 0.14 que contém a

informação de Status de Ativa da CPU, e escreve o valor correspondente no endereço de

memória WM 1.14. Na seqüência, são criados outros dois acessos, sendo uma leitura (Remota

para Local) e outra escrita (Local par Remota), que não serão realizadas sempre, mas somente

quando a CPU for ativa.


Figura 19.4 – Configuração Trigger, Leitura e Escrita Modbus TCP – CPU Ativa

Figura 19.5 – Configuração Trigger, Leitura e Escrita Modbus TCP – CPU Standby

Sendo assim, como esta comunicação é criada para ambas as CPUs, as leituras e

escritas serão sempre realizadas somente na CPU Ativa e nunca na CPU Standby. Lembrando

que esta condição somente será necessária quando a ethernet estiver configurada para utilizar

IPs diferentes nas duas CPUs.

1. Trigger que monitora quando CPU está Ativa (ST 0.14)

2. Leitura da CPU Remota para CPU Local somente quando CPU Ativa

3. Escrita da CPU Local para CPU Remota somente quando CPU Ativa


19.2 CPUs utilizando mesmos endereços IP

Nesta situação em que as CPUs utilizam os mesmos IP, sendo que a CPU Standby

subtrai 1 (um) do IP configurado, sabe-se que no momento do Switchover, haverá a troca dos

IPs entre as CPUs.

Sendo assim, em conexões realizadas entre duas CPUs Redundantes ou entre uma

CPU Redundante e uma CPU não redundante, a configuração será basicamente como se fosse

um sistema sem redundância, ou seja, a conexão será feita apenas para a CPU Ativa, e quando

houver um Switchover a conexão será conectada a nova CPU em um tempo menor que 3 (três)

segundos.

Em ambos os exemplos a seguir, a conexão será realizada entre os IPs 192.168.1.100

e 192.168.1.50, porque mesmo que haja um Switchover, esses sempre serão os IP das CPUs

Ativas.

Figura 19.6 – Comunicação entre CPUs Redundantes com IPs

Iguais Figura 19.7 – Comunicação entre CPU Redundante e CPU Não

Redundante com IPs Iguais

Para ambas as topologias propostas acima, quando houver um Switchover a conexão

será conectada automaticamente a nova CPU Ativa, e este processo pode levar até 3 (três)

segundos. Diante disso é importante que após este tempo caso o status de erro da conexão

permaneça como falha, tomar ações pertinentes ao processo considerando falha na

comunicação com a variável monitorada.


20 Configuração Sistemas Supervisórios

Para o sistema redundante utilizando PLC Citrino, é altamente recomendável que a

comunicação com sistemas supervisórios seja realizada através de comunicação entre

servidores e clientes OPC redundantes.

A topologia apresentada a seguir ilustra um exemplo utilizando PLC Citrino

Redundante com Servidores OPC Redundantes e vários clientes OPC.

Figura 20.1 – Topologia do Sistema de Supervisão utilizando OPC

A comunicação do servidor OPC com o Citrino será via protocolo Modbus/TCP, o qual

deverá ter conexões tanto com o endereço IP da CPU Ativa quando da CPU Standby.


A Fertron não restringe a utilização de servidores OPC a um único fabricante,

deixando em aberto para escolha do cliente, desde que o protocolo Modbus/TCP atenda as

normas internacionais deste protocolo.

Todos os testes de servidores e clientes OPC para o Sistema Redundante com Citrino

foram realizados utilizando KepServer do fabricante KepWare, o qual recomendamos para

estas aplicações.

Para detalhamento de como configurar o servidores e clientes OPC da KepWare foi

disponibilizado um manual contendo as informações necessárias, além da consulta ao próprio

manual do fabricante.


21 Realizando UpLoad e Download no Sistema Redundante

Sempre que for utilizada a opção de pesquisa do “Citrino Tools” para pesquisa das

CPUs que estão disponíveis, em um conjunto redundante aparecerão as duas CPUs

identificando que fazem parte de um sistema redundante, porque na prática, o Citrino Tools

deverá sempre se conectar com a CPU que estiver em modo Ativo.

Na primeira coluna desta janela, o ID (Identificador) mostra se é uma CPU RD

(Redundante) ou SD (Standard = Não redundante). Além de outras informações nas colunas

posteriores, informando qual o “Status” atual da CPU e qual o modo de operação da mesma.

Figura 21.1 – Pesquisa por CPUs Disponíveis

Quando houver uma ação de UpLoad, sempre que for solicitada pelo Citrino

Tools, todas as informações serão lidas sempre da CPU Ativa, porém quando a ação for

Download, o software enviará, automaticamente, as informações tanto para a CPU Ativa

quanto para a CPU Standby de forma a mantê-las com a mesma configuração, porém existem

algumas características especificas a serem observadas, como se apresenta nos itens

seqüentes.


21.1 Download de Memórias e TAGs, Ladder, Modbus RTU e Modbus/TCP

Quando a escolha do armazenamento (download) for dos itens Memórias e Tags,

Ladder, Modbus-RTU ou Modbus-TCP, a informação de configuração será enviada

automaticamente para as duas CPUs, sem que haja qualquer interrupção do sistema, e

mantendo as CPUs com a mesma configuração e sincronizadas.

Figura 21.2 – Download Memórias e Tags, Ladder, Modbus-RTU e Modbus-TCP

21.2 Download em Módulos Profibus

Quando a escolha do armazenamento (download) for em um ou mais módulos

Profibus, alguns detalhes precisam ser levados em consideração, como mostrados na

seqüência.

Figura 21.3 – Download em Módulos Profibus


Toda vez que um módulo Profibus recebe uma nova configuração através de um

novo armazenamento (download), o mesmo precisa executar um reset do próprio módulo

para que as novas configurações sejam atribuídas. Essa característica em um sistema não

redundante, certamente levaria a parada da operação.

Porém com o sistema redundante, isto se tornou uma opção escolhida nas

configurações do Sistema Redundante que evitam a interrupção da operação.

Figura 21.4 – Configuração do Download sem Parada em Módulos Profibus

Na configuração do sistema redundante, a opção “Download Sem parada dos

módulos Profibus”, quando:

• Opção Selecionada: neste caso quando ocorrer um download, o mesmo será realizado

primeiramente na CPU Standby, que assim que receber toda a configuração e após 10

segundos de reset ocorrerá o Switchover entre as mesmas, permitindo então que o

download inicie automaticamente na outra CPU, ao fim, ocorrerá novamente o

sincronismo entre as duas CPUs, e a operação voltará para a CPU que estava em modo

ativo no inicio do download. Esta sistemática permite que em nenhum momento ocorra a

parada do sistema, porque os escravos do módulo Profibus que estão recebendo a nova

configuração sempre terão um mestre ativo comunicando com os mesmos.

• Opção Não Selecionada: neste caso quando ocorrer o download, o mesmo será realizado

simultaneamente nas duas CPUs, sendo que todos os escravos do mestre Profibus que

está recebendo a nova configuração perderão comunicação ao fim do download devido

ao reset que ocorrerá no módulo.

Nota Importante:

Não é possível realizar um Download “sem parada” nos Mestres Profibus,

quando houver alteração na “Taxa de Transmissão” (Baud Rate).


21.3 Sincronização de configurações diferentes

Caso uma CPU seja iniciada após a outra, ou mesmo simultaneamente, e não ocorrer

a autonegociação entre as mesmas, é necessário verificar através do “Citrino Tools” quais os

motivos não estão permitindo a sincronização entre as mesmas, na opção � Ferramentas /

Redundância / Diagnóstico de Redundância.

Caso o motivo seja “CPUs com configurações diferentes”, possivelmente porque

houve algum download enquanto ambas estavam dessincronizadas, é possível realizar a

sincronização de forma fácil e rápida, através da opção “Sincronizar” disponível no Citrino

Tools, como mostram as imagens a seguir.

Certifique-se de que a CPU que está como status Ativa é a CPU que contém a

configuração que realmente é a mais recente, porque todo o conteúdo desta CPU será

transmitido para a outra no momento da sincronização.

Figura 21.5 – Sincronização de Configuração entre CPUs

Figura 21.6 – Confirmação de Sincronização entre CPUs

Caso ocorra qualquer tipo de exceção, e a sincronização não aconteça, faça

manualmente o “UPLOAD” de configuração da CPU Ativa, conecte o computador via cabo

ethernet diretamente na CPU Não Configurada, e realize o “DOWNLOAD” na mesma. Consulte

sempre a ferramenta de diagnósticos para saber qual o problema apresentado caso não haja

sincronização, como mostra o capítulo a seguir.


22 Diagnósticos de Erros e Eventos do Sistema Redundante

Os diagnósticos contêm todas as informações das ações importantes ou eventos de

falha de todo o sistema. Neste caso específico da redundância, foi criada uma aba no “Citrino

Tools” de diagnósticos específicos dos eventos relacionados à redundância, que certamente

poderão ajudar a entender qualquer situação de desqualificação, Switchover e até mesmo

problemas com a inicialização do sistema. Serão listados os últimos eventos com data, hora e a

descrição do que significa o registro em questão.

Figura 22.1 – Diagnóstico de Erros e Eventos do Sistema Redundante

Exemplos: Evento Descrição CM_NAC Comando não reconhecido, possível problema com a fibra DT_ERR Dados recebidos incorretos, possível problema com a fibra FO_ERR Erro na fibra óptica IP_ERR Erro de IP durante auto-negociação, verificar configurações de IP CK_ERR Checksum de configuração está diferente nas duas CPUs FB_ERR Firmware do Processador das CPUs está diferente, utilize CPUs idênticas FF_ERR Firmware do FPGA das CPUs está diferente, utilize CPUs idênticas MC_ERR Endereço do MAC das duas CPUs são iguais, contate o fabricante Fertron PO_ERR Erro fonte de alimentação MD_ERR #1 Erro no módulo, slot 1 SYNC_ERR CPUs dessincronizadas SWO_PWD Switchover pelo motivo de fonte de alimentação SWO_SFC Switchover pelo motivo de software configurador SWO_LAD Switchover pelo motivo de solicitação da lógica ladder SWO_HRW Switchover pelo motivo de falha no hardware SWO_FBC Switchover pelo motivo de falha no cabo Fieldbus SWO_ETC Switchover pelo motivo de falha no cabo Ethernet SWO_SEC Switchover pelo motivo de falha no cabo Modbus SWO_ABM #2 Switchover pelo motivo de módulo ausente (retirado) no slot 2


23 Restrições

A Fertron não se responsabiliza pelo mau uso das informações contidas neste

manual, e sugere a utilização dos serviços de assistência técnica da própria Fertron para

integração do sistema redundante utilizando MCPU-2 Citrino, e/ou a realização dos

treinamentos pertinentes através do setor de treinamentos da empresa, o qual irá oferecer

todas as condições necessárias para utilização deste produto.


24 Informações Adicionais

Como descrito nos itens:

• 5 - Topologias de Rede Profibus permitidas e não permitidas, quando se trata de

aplicações com fibra óptica em anel, utilizando conversores Profibus para fibra óptica

• 17 - Características Fibra Óptica, quando se trata de lances de fibra óptica maiores que

2 metros, necessária customização e certificação do link.

Ambas as situações são características que podem ser agregadas ao sistema

redundante em determinadas aplicações, e que possivelmente poderão ser realizadas por

outras empresas escolhidas pelo próprio cliente. É importante que em caso de dúvidas quanto

a essas aplicações o setor de suporte ao cliente e/ou assistência técnica da Fertron seja

acionado para fornecer toda experiência e informações necessárias para esses tipos de

aplicações.


25 Perguntas e respostas freqüentes (FAQS)

Este tópico foi criado para responder a possíveis dúvidas que tenham permanecido

quando da leitura do manual. O conteúdo exclusivo deste tópico não dispensa a leitura

completa deste manual, que ao longo de todos os tópicos traz informações necessárias para a

compreensão total do sistema redundante, porém certamente contribui de forma a

complementar as informações já apresentadas no decorrer deste manual ou até mesmo a

direcioná-los ao local correto da informação.

• Posso iniciar um sistema antes do outro ou preciso iniciar os dois ao mesmo tempo?

R: Você pode iniciar os sistemas ao mesmo tempo ou em tempos distintos. Quando

um sistema é iniciado, ele tenta a auto-negociação com seu parceiro por 10 segundos, caso

não haja nenhuma resposta o mesmo se tornará ativo e ficará aguardando que seu parceiro

esteja comunicando para entrarem em sincronismo. (Detalhes no item 7)

• Eu vejo uma colisão nas saídas durante um Switchover?

R: Não há nenhum tipo de colisão nas saídas, a partir do momento que ocorre um

Switchover, o próximo ciclo de scan já será executado pela CPU que se tornou ativa,

assumindo o controle total sem nenhuma colisão. (Detalhe no item 16)

• No momento do Switchover meu processo irá parar?

R: Não, seu processo continuará funcionando corretamente sem nenhuma

interrupção do sistema, esta é a principal funcionalidade do sistema redundante.

• Como o segundo controlador se mantém atualizado?

R: Após o procedimento inicial de auto-negociação, as CPUs realizando entre sim o

Crossload, que nada mais é do que uma cópia das informações alteradas na CPU Ativa para a

CPU Standby, realizada a cada ciclo de Scan, o que mantém as duas CPUs sempre atualizadas

entre si.


• As duas CPUs possuem o mesmo endereço de IP ou são diferentes?

R: Isto é configurável, mas a configuração padrão prevê que a duas CPUs sejam

configuradas com o mesmo endereço de IP, porém após ser realizada a auto-negociação a CPU

Standby terá seu IP reduzido de 1 (um). (Detalhes no item 6.2)

• O que acontece com o endereço de IP durante um Switchover?

R: Durante o Switchover há uma inversão de IPs entre as duas CPUs. Mas esta opção

pode ser alterada em configuração pelo “Citrino Tools”. (Detalhes no item 8.1)

• Quando faço qualquer alteração de configuração ou na lógica de controle, preciso

atualizar nas duas CPUs?

R: Não, você faz a alteração no “Citrino Tools” e no momento do armazenamento, o

próprio sistema irá enviar a nova configuração para as duas CPUs, sem que você precise se

preocupar com qualquer ação neste sentido. (Detalhes no item 21)

• No momento do download de configuração, meu processo irá parar ?

R: Com o sistema redundante, é possível você fazer qualquer alteração, até mesmo

em módulo mestre Profibus, sem que haja interrupção do processo. (Detalhes no item 21.2)

• O tempo de Scan aumenta devido à redundância?

R: Sim, devido ao Crossload que ocorre entre as duas CPUs para mantê-las

atualizadas, esse tempo de cópia de uma CPU para outra, aumenta o tempo de Scan, porém

são valores muito baixos. Quanto maior for sua lógica de controle, maior poderá ser esse

tempo, variando na ordem de milissegundos. (Detalhes no item 16.1)

• Posso definir qual CPU será ativa?

R: Sim, você pode na configuração do sistema redundante definir qual CPU você

gostaria que operasse como Ativa. No momento da auto-negociação esta configuração será

respeitada. E isso não impede que a CPU Standby assuma o controle no momento de qualquer

falha. (Detalhes no item 6)


26 Glossário

Termo Descrição

Auto-negociação É a troca de informações entre as duas CPUs que definir qual delas irá operar em modo ativo ou em modo Standby

CPU Central Processing Unit (Unidade Central de Processamento)

CPU Ativa CPU operando em modo Ativa, responsável pela execução do controle do sistema

CPU Desqualificada Quando há falha em qualquer dos módulos ou cabos e a CPU não está disponível para sincronização no sistema.

CPU Dessincronizada Quando as duas CPUs não possuem a mesma informação em suas memórias ou alguma delas está desqualificada, sendo assim, nesta situação elas não estão trocando dados e o sistema redundante não está operante

CPU Qualificada Quando não há falha em nenhum componente do sistema e o mesmo está pronta para sincronização

CPU Standby CPU operando em modo Standby, responsável por assumir o controle em caso de falha da CPU Ativa

Crossload É a transferência de qualquer ou todo o conteúdo da CPU Ativa para a CPU Standby. O Crossload acontece após as CPUs estarem negociadas e ocorre a cada ciclo de “scan” mantendo os dois sistemas sincronizados

Download Armazenamento da configuração a partir de Software de Configuração

Fail-Safe Um dispositivo de falha segura é aquele que em caso de falha responde de forma que não irá provocar nenhum dano a outros dispositivos, pessoas ou ao ambiente.

Fault-Tolerant Se qualquer elemento do sistema apresentar falha, todo o conjunto é desativado e o sistema Standby assume o controle, mantendo a operação do sistema sem interrupção

IHM Interface Homem Máquina, por exemplo, sistema supervisório ou as próprias IHMs instaladas em campo

Módulos E/S Módulos de entradas e saídas

OPC Open Productivity & Connectivity, é um padrão de comunicação utilizado em sistemas de automação industrial

PLC Programmable Logic Controller (Controlador Lógico Programável)

Retries Repetições

Sincronização Momento em que a CPU Ativa está transferindo todas as informações como configuração, lógica, tags e parametrizações para uma CPU que acabou de se tornar Standby

Sincronizado Quando as duas CPUs estão com a mesma informação na memória e atualizando os dados a cada ciclo de “scan”


Termo Descrição

Sistema Ativo É todo o conjunto de módulos, com Fonte, CPU e Mestre Profibus, que estão operando em modo Ativo

Sistema Primário É uma nomenclatura apenas para definir primeiro sistema de dois. O

Sistema primário não necessariamente será o sistema Ativo.

Sistema Secundário É uma nomenclatura apenas para definir segundo sistema de dois. O

Sistema secundário não necessariamente será o sistema Standby.

Sistema Standby É todo o conjunto de módulos, com Fonte, CPU e Mestre Profibus, que estão operando em modo Standby

Switchover Quando ocorre alguma condição de falha no Sistema Ativo, e o controle é alterado para a CPU Standby, tornando o Sistema Standby em Ativo.

Timeout Tempo máximo estabelecido para considerar uma comunicação em falha

UpLoad Leitura dos dado que estão na CPU através de Software de Configuração

Tabela 26.1 – Glossário


27 Conclusões Finais

Através deste manual, é possível aos integradores de sistemas obterem todas as

informações pertinentes a utilização da MCPU-2 Citrino como um sistema redundante. O

manual aborda todas as situações necessárias para colocada do sistema em operação, assim

como informações sobre o comportamento do sistema em situações problema.

Caso alguma dúvida tenha permanecido após a leitura deste manual, você pode

entrar em contato com o Suporte ao Cliente para informações adicionais.

Fertron Controle e Automação Industrial

Suporte ao cliente: Email: [email protected]

Fone: (16) 3946-5899

Se houver qualquer sugestão que possa aprimorar este documento, envie seus

comentários para o endereço de email [email protected] e suas observações

certamente servirão para tornar esta documentação melhor.

sistema de automação redundante com plc citrino · figura 12.1 – perda do cabo ethernet –...

Documents