terça-feira, 7 de dezembro de 2021

O que é SoE Sequece Of Events ?

 Nesse breve artigo pretendo descrever um pouco do que é SoE e o porquê isso afeta tanto os projetos de controles voltados para automação em sistemas elétricos.


O mais fácil é explicar o que não é SoE através de um exemplo.

Vamos ao exemplo prático: consideremos dois PLC’s conectados a uma IHM via MODBUS. Essa comunicação MODBUS tem um ciclo de scan de 1 segundo, a cada 1 segundo todas as informações são requisitadas pela IHM dos dois PLC’s, primeiro do PLC1 e logo depois do PLC2. Os dois PLC’s 1 e 2 monitoram um relé que possui dois contatos.






O que acontece quando o contato é fechado?


Quando o contato se fecha, os PLC 's recebem através de uma entrada digital a informação de contato fechado que é materializada no “mundo digital” através de uma variável binária geralmente em estado alto, “1” lógico. Esse tempo de processamento demora geralmente dezenas de microsegundos.


Ainda dentro do PLC o sinal da variável é transmitido para o driver modbus e disponibilizado através de uma tabela para acesso externo. Quando o PLC diz que têm um driver nativo, significa que esse sinal é transmitido imediatamente, ou seja, não há tempo demandado entre a detecção do sinal e a disponibilização no driver. Em outros casos, e até mesmo por conta da boa prática na programação, esse sinal é transmitido através de lógica de controle o que demanda pelo menos um ciclo de trabalho completo do PLC para que o dado fique disponível na tabela MODBUS.


Uma vez que temos o dado materializado na interface MODBUS temos a necessidade de que a IHM “busque” esse dado para apresentar na tela. Para isso, a IHM têm um driver modbus que faz uma leitura dessas informações. Vamos considerar a existência de um único driver MODBUS na IHM, isso quer dizer que primeiro é feita a leitura de um PLC e depois do outro PLC, os dois PLC’s não são lidos simultaneamente.



A IHM lê todo o vetor de informações disponíveis pelo PLC1 e armazena essa informação internamente em algum tipo de banco de dados. A fim de dar uma cronologia todos os dados são estampados com uma data no momento que a informação entra nesse banco de dados da IHM. Instantes depois quando o PLC2 é lido ocorre a mesma coisa, o driver identifica a variação do ponto e estampa a entrada desse dado no banco de dados com uma data e hora levemente a frente da dada do PLC1.



Assim quando vemos na tela o mesmo contato que foi fechado no mesmo instante no pátio estampado na tela pelos dois PLC’s temos datas de ocorrência diferentes e nenhum deles reflete o tempo correto que o contato foi fechado em campo isso porque:

  1. Temos uma latência inerente do processo de aquisição e transmissão da informação, assim o tempo t1 não é o tempo que o evento aconteceu de fato e sim o tempo em que a IHM detectou a primeira vez a informação acrescida do tempo de aquisição do PLC, o Tempo de processamento interno do PLC, o tempo do driver modbus e o tempo de transmissão da informação entre os dispositivos.

  2. Como o driver não consegue saber o tempo em que o PLC recebeu a informação o PLC2 parece ter um atraso maior, mas na verdade isso é uma consequência da leitura da IHM.

  3. O tempo decorrido nem sempre é fixo, pode variar, por exemplo, do congestionamento do dado na rede Ethernet ou dos conflitos de dispositivos presentes em uma rede RS485.



Na maior parte dos processos industriais não existem dois equipamentos aquisitando o mesmo ponto, tão pouco existe a necessidade de que a informação tenha um grau de precisão elevado. 1 segundo de taxa de amostragem é satisfatório para maior parte dos processos mecânicos.


Modbus, OPC, Profibus, EtherCAT, todas essas comunicações são plenamente aceitáveis nesses processos o que facilita muito a programação e a escalabilidade da solução. Nestes protocolos um dado binário é apenas uma entidade binária transmitida entre os dispositivos em que a IHM se encarrega de atribuir um dado temporal ao dado.


Outro aspecto é que a comunicação, o meio deve ser sempre uma via segura e inabalável. Isso quer dizer que se houver uma desconexão todos os pontos são transmitidos imediatamente ao retorno da conexão e estampados com esse momento, não há um buffer, não há uma estrutura que permita analisar esse dado a posteriori.


A necessidade do SoE veio exatamente desse tipo de fragilidade. Então como não ter essa dependência do tempo de comunicação entre os dispositivos para ter essa informação exata disponível na tela?


Um caso que é necessário SoE


Quando temos sistemas elétricos em que a velocidade de uma onda senoidal é 60Hz, ou seja, em 16,67 ms a tensão sai de zero e excursiona entre o máximo positivo e o máximo negativo os processos precisam acontecer nessa ordem de grandeza não seria aceitável que em um sistema dois disjuntores fossem estampados na tela com o mesmo segundo de abertura.



Neste exemplo temos um sistema radial entre um gerador e uma carga com dois disjuntores e uma linha de transmissão entre eles. Digamos que ocorre uma falta nas proximidades da carga e os dois disjuntores abrem e temos um sistema sem SoE para apresentar os alarmes na tela então temos a seguinte profusão de sinais na tela:




Como todos os eventos chegaram no mesmo segundo, não é possível estabelecer uma relação de causa e efeito, todos os eventos chegaram no momento em que foram adquiridos pelo dispositivo que está mostrando os dados.


A essa altura poderia se imaginar que seria possível deixar esses tempos mais rápidos de modo que fosse possível diferenciar estes sinais e permitir uma visualização temporal dos dados.


O SoE é exatamente isso, uma especificação que permite garantir que os sinais tenham uma discretização temporal de no máximo 1 ms.


SoE


SoE quer dizer sequence of events que trata de uma infraestrutura necessária para que um dispositivo consiga identificar e transportar uma informação até os terminais de saída (tela, impressora, histórico) a informação de um ponto digital que mudou de estado em uma discretização tal que os eventos possam ser diferenciados na ordem de 1 ms.


No mesmo exemplo acima se tivéssemos um sistema DCS com SoE teríamos algo como os eventos a seguir:




Veja que é possível identificar que ambos os disjuntores identificaram a falta, o DJ2 abriu, sinalizou uma falha durante a abertura, o que acarretou uma transferência da falta para o DJ1. O DJ1 não foi acionado pela falta em si mas pela falha no primeiro elemento de proteção DJ2.


Alguns aspectos do SoE


  • Como no SoE um ponto se torna uma sucessão de eventos de variação desse ponto, onde cada variação é identificada e transmitida com uma informação temporal;

  • Vários dispositivos com SoE podem transmitir informação de uma forma combinada e mesmo com origens distintas é possível organizar as informações cronologicamente no prompt de saída.

  • Como a informação de um ponto não é apenas um booleano puro é necessário que cada mudança de estado seja transmitida com informações de data, hora, qualidade dessa informação então é necessário um protocolo de comunicação que comporte essa informação de maneira adequada.

  • Note que do ponto de vista do SoE o ponto deixa de ser um booleano e passa a ser um controle de variações temporais de uma entrada booleana. Quando o SoE está funcionando podemos identificar pelo log de eventos todas as vezes que a variável mudou de status de fato.




Construindo uma solução com SoE


Então vamos agora reconstruir o exemplo inicial para uma configuração que permita que exista SoE entre as aquisições.


O primeiro passo para isso é identificar qual dispositivo será o elemento com SoE: Quem fará o carimbo da informação temporal no sinal proveniente do campo? 


Neste caso serão os dois PLC’s, isso quer dizer que os PLC’s precisarão receber um sinal de sincronismo de tempo, afinal, para os dois precisam ter algum marco temporal interno para controlar qual dada a informação de variação do ponto ocorreu.


Nessa condição toda vez que a entrada sofre a variação 0->1 ou 1->0 um driver nativo captura essa informação e a inclui numa pilha de informações interna do PLC independente do processamento. Esse trabalho de empilhamento das informações internamente ao dispositivo é inútil se o dispositivo tiver uma IHM ou uma forma de externalizar por si só as informações. Se o dispositivo não possui essa alternativa é necessário transportar essa informação para o mundo exterior através de um protocolo que não descaracterize essa informação.




O protocolo MODBUS, por exemplo, não tem capacidade de enviar as informações correlatas para uma variação de um ponto digital. Assim sempre tratamos de SoE, tratamos também de protocolos que permitem o transporte de eventos com a estampa de tempo. Esse é o caso do IEC 60870-5-104, IEC 60870-5-101, IEC 61850, DNP3 etc.


Estes protocolos são protocolos desenvolvidos para transporte de eventos com estampa de tempo e por isso são adequados a transportar a informação.


Assim, no nosso exemplo, utilizaremos por exemplo a comunicação IEC 60870-5-104. No protocolo IEC 104 os eventos são enviados conforme são empilhados para o dispositivo mestre. A transmissão de um evento relacionado ao um ponto via  IEC 104 é um pacote de informação completo, uma espécie de estrutura em que é enviado além do estado atual do ponto booleano, o momento que ele assumiu esse estado (data e hora), se o ponto está sendo simulado no PLC através de um comando de force, se o ponto está válido na origem (qualidade da informação).


Assim temos uma rede adequada para transmissão de pontos booleanos com SoE as informações são enviadas para IHM com a informação de tempo já gerada não importa quanto tempo demora a transmissão desse dado, ou até mesmo a retransmissão do dado a informação do momento que o ponto foi criado não se perde.



Assim para o nosso exemplo teríamos na tela a informação dos dois PLC’s sendo recebida em tempos diferentes pela IHM mas com a estampa original do momento exato que o evento aconteceu, isso é SoE: ter uma discretização menor que 1 ms entre pontos digitais no mesmo supervisório provenientes de diversas origens e sincronizados entre si.



Numa próxima oportunidade trarei aspectos interessantes que estão subliminarmente ligados ao SoE e as comunicações utilizadas quando o SoE está em funcionamento.


domingo, 21 de novembro de 2021

Considerações sobre a supervisão das bobinas de abertura (95)



Existe uma preocupação especial sempre com os circuitos de trip dos disjuntores, na verdade, toda a infraestrutura requerida pelo ONS tem o objetivo de minimizar possíveis problemas que causem a não abertura do disjuntor na presença de uma falha.

Pelos padrões atuais dos Procedimentos de Rede os disjuntores devem ter duas bobinas de abertura por disjuntor que são acionadas por elementos duplicados de proteção; que por sua vez possuem origens de medição de enrolamentos distintos do TC. Assim podemos constatar que o sistema de proteção é um controle completamente redundante, desde a instrumentação (TC) até o elemento de controle (bobina de abertura).

A bobina de abertura geralmente é fria, quando submetida a uma corrente elétrica ativa um mecanismo composto por uma mola carregada que abre rapidamente o contato principal do disjuntor. Geralmente um disjuntor é fornecido com duas bobinas de abertura em que ambas têm plena capacidade de desencadear o processo mecânico de abertura do disjuntor.

Discussões sobre redundância à parte, naturalmente não é todo o dia que um disjuntor abre por uma falha, ou seja, não é tão constante assim um disjuntor abrir. Assim como temos em nossa casa, em que a maior parte das vezes usamos os minidisjuntores do painel de luz como interruptores para seccionar os circuitos, é muito raro acontecer um acionamento próprio do mini disjuntor por seu elemento interno de sobrecorrente.

Nos sistemas de potência é algo parecido, a proteção não atua, ou não deveria atuar com uma frequência maior que uma vez por ano. A rigor, o elemento mais suscetível a falhas, as linhas de transmissão, que são dimensionadas para uma taxa de falha inferior a 1 desligamento a cada 100 km por ano. Então podemos supor que um disjuntor de uma linha de 100km tenha um acionamento por falha entre 1 a 2 vez por ano!

Imagine, todo esse circuito de abertura só é acionado 1 vez por ano. Tudo pronto para um instante de milésimos de segundo, analisando a probabilidade seria algo como 0.000000000031710!








Em um circuito normal de abertura temos a bobina do disjuntor instalada em uma caixa de comando no pátio imediatamente abaixo do mecanismo do próprio disjuntor, um cabeamento que se estende desde o disjuntor até o painel no qual um ou mais contatos secos podem executar o comando de abertura desse disjuntor mediante a identificação de uma falta.

Então temos alguns pontos fracos nesse esquema:

  1. Podemos ter uma falha de cabeamento: basta que qualquer borne, cabo ou veia se parta que esse acionamento não ocorra.
  2. Podemos ter um dano interno no painel de proteção - A fiação interna pode se desconectar ou um borne pode se afrouxar pela vibração natural do painel.
  3. Podemos ter uma falha na própria bobina do disjuntor - é possível que a bobina se danifique de alguma forma afinal a bobina do disjuntor fica instalada dentro do corpo do disjuntor no pátio submetido a sol, chuva, variação de temperatura, umidade e algumas vezes até mesmo a sais pesados.
  4. Um curto-circuito em algum ponto do circuito com uma fonte externa - o circuito é alimentado através do potencial CC da subestação que geralmente vai até o disjuntor pelas canaletas do pátio, o que também pode ter falha, canaletas alagadas, danificação de isolamento de cabos são possíveis.
  5. Perda de potencial no circuito de abertura - Pode haver uma perda do potencial por rompimento do cabo de alimentação CC.
A questão é, como saber que tudo está em conformidade para o instante exato quando for necessário abrir o disjuntor?

A função ANSI 95

Para essa finalidade foi pensado um dispositivo próprio de supervisão denominado por relé TCS (Trip Circuit Supervision) - já vi também como CBS – (Circuit Breaker Supervision). Geralmente é representado pelo número 95, que é o código ANSI.

O relé supervisiona o circuito de trip do disjuntor e dá um alarme se alguma das anormalidades abaixo for encontrada.



Geralmente o elemento 95, o relé TCS, faz a supervisão direta da bobina de trip, ou seja, ele ‘vê’ o potencial positivo puro recebido pelo disjuntor contra o potencial negativo refletido pelo lado A1 da bobina do disjuntor quando o circuito de abertura está aberto.

Enquanto não ocorre o comando de abertura, o relé 95 é excitado com o potencial que está sobre a bobina. Se esse potencial se esvair por qualquer motivo temos uma falha na supervisão da bobina de disparo.



Se houver qualquer dos problemas relatados anteriormente, o relé 95 perde o potencial e o contato de supervisão e abre. Assim caracterizando uma falha no circuito de abertura.

Um fato interessante: quando ocorre o trip, o disjuntor recebe o comando de abertura, o potencial sobre o relé 95 vai a zero se transferindo integralmente para a bobina de abertura do disjuntor, neste instante acontece uma atuação indevida do sinal de supervisão da bobina de abertura. Geralmente esse sinal espúrio pode ser contornado através de uma lógica no sinal de supervisão, seja no sistema de controle ou no sistema supervisório.



A instalação do relé 95 em disjuntores da rede básica é obrigatória pelos procedimentos de Rede do ONS. Mesmo que não fosse, é sempre bom ter uma supervisão no circuito de abertura e fechamento dos disjuntores a fim de antever um possível problema mais sério que seria a não abertura do disjuntor.

É importante ressaltar que a supervisão das bobinas de abertura é um elemento forte para necessidade de intervenção no disjuntor para manutenção. Se você têm nos seus sistemas atuações constantes do sinal de falha da bobina de abertura em diferentes disjuntores pode ser um caso de investigação mais profunda sobre o tema.

quarta-feira, 10 de novembro de 2021

Noções básicas do sistema SCADA

 


Como bem sabemos SCADA é uma sigla que significa Supervisory Control And Data Acquisition ou em português o Controle de Supervisão e Aquisição de Dados. O SCADA hoje pode ser definido como um software para controle de processos que roda em um computador que realiza a aquisição de dados e interface de comunicação com um ou mais dispositivos. 


Antigamente existiam estações SCADA, microcomputadores com um sistema digital embarcado próprio capaz de realizar um gerenciamento em tempo real da aquisição, e impressão dos dados numa tela ou em uma impressora matricial. Não havia o conceito de RTOS Runtime Operational System como o Windows e o Linux, trata-se que o próprio SCADA tinha em si os drivers para o teclado, tela, impressora e aquisição de dados. Com o passar do tempo o SCADA se tornou um software sobre um sistema operacional comercial.


Na década de 80 e 90 poucos hardwares existiam disponíveis, iniciativas como a Cobra computação associada ao Banco do Brasil faziam sentido. No final da década de 90 e até os dias atuais muitos fabricantes entraram no mercado e com uma variação de produtos quase impensável naquela época. Só a NVIDIA possui uma coletânea de  2 mil placas de vídeo com suporte ativo , não é atoa que existe um software que gerencia drivers da NVIDIA. Essa variação de hardwares fez com que o SCADA precisasse migrar para um software que operasse em conjunto com o sistema operacional em tempo real principalmente Windows e o Linux. Mais ainda, essa necessidade permitiu que as empresas direcionassem os esforços na evolução da sua própria plataforma e não mais na compatibilidade com o hardware.


SCADA é um sistema de controle central que consiste em interfaces de rede do controlador, equipamento de comunicação de entrada ou saída e software. O Sistema SCADA realiza o controle e monitoramento do processo industrial.


Nessa atribuição o SCADA coleta os dados de uma ou mais instalações, além de enviar comandos básicos de controle para as instalações O objetivo do SCADA é tornar desnecessário que um operador humano esteja permanentemente presente no local das instalações para as operações corriqueiras previstas no dia-a-dia da planta industrial.


Sendo assim podemos concluir que conceitualmente o SCADA é uma combinação de uma unidade de impressão de dados tela/impressora hoje tratado como telemetria e uma outra parte destinada a aquisição de dados.


Aquisição de dados:


Aquisição de dados refere-se ao método usado para coletar ou enviar dados/informações de/para o equipamento que está sendo controlado e monitorado. Os dados acessados são então encaminhados para um sistema de telemetria pronto para transferência das diferentes unidades de impressão como telas, gráficos, mostradores virtuais etc...


Naturalmente esses dados podem ser digitais ou analógicos coletados dos mais diversos sensores e equipamentos, podendo ser inclusive um dado com relativo temporal, ou seja, acompanhado de uma data e hora em que aquele dado foi recebido.


Monitoramento:


O monitoramento ou telemetria é simplesmente a maneira com que o SCADA mostra os dados coletados pelo sistema. Para tal finalidade o sistema SCADA geralmente é munido de um conjunto de base de dados onde os dados aquisitados são coletados e disponibilizados para as diferentes formas de telemetria disponíveis como apresentação gráfica em uma tela desenhada com o processo, ou rastreamento instantâneo de uma grandeza através de um gráfico. Outras formas também são possíveis, como uma tabela de variáveis ou um relatório instantâneo discretizado.




Naturalmente existem outros submódulos ligados a um sistema SCADA. Podemos destacar o armazenamento de dados de histórico de um processo. Geralmente os sistemas SCADA comerciais possuem módulos adicionais para armazenamento de dados durante longos períodos de tempo sem consumir tanto armazenamento e permitindo que esses dados sejam acessados através das janelas de telemetria.


É importante ressaltar que o conceito de SCADA, DCS, Supervisório e IHM às vezes se confunde. O SCADA seria um sistema de aquisição de dados, não é previsto grandes automatismos através de um célula de aquisição, entretanto os PLC’s atuais permitem ser esse “braço” de aquisição de dados ao mesmo tempo que realizam um controle e supervisão de unidades de I/O remotas. Os PLC’s incluem até mesmo controladores complexos PID.


Um distributed control system (DCS) completo seria um conceito mais válido para os sistemas atuais + um supervisório embarcado em computadores.


Podemos ver um exemplo para que esse conceito fique mais claro: imagine um sistema composto com um supervisório Elipse + PLC Schneider aquisitando dados ao mesmo tempo que possui um dispositivo de aquisição modbus da Altus. Esse conjunto é um SCADA.



Como é a arquitetura de um sistema SCADA ?


Podemos dividir o sistema SCADA em alguns componentes básicos que são comumente presentes na maior parte dos projetos:


- Estação remota (RTU -Remote Terminal Unit )

- Rede de comunicação

- Estação mestre (MTU - Master Terminal Unit)

- Unidade de processamento de dados (client)



RTU:


Os instrumentos de campo são conectados às RTU’s (Remote Terminal Unit) e ao circuito de controle, A RTU nada mais é do que um PLC dispositivo PLC dedicado para aplicações remotas que possui um terminal de comunicação e consegue exercer todas as funções de controle internamente. A RTU coleta dados dos instrumentos de campo sobre parâmetros de processo e status de alarme. Ele mantém as informações até que o MTU as solicite. E a MTU comanda a RTU para alterar o setpoint e alterar a variável de processo por meio de ações de controle, como fechar ou abrir válvulas, ligar/desligar a saída etc...


A RTU/PLC recebe todos os dispositivos de campo. E recebe ordens de controle discretas, instruções de configuração e transmite de volta aos equipamentos de campo provenientes de uma estação mestre MTU.


Normalmente RTU podem ser PLCs, DCS.


MTU:


MTU’s (Master Terminal Unit) lêem e gravam dados de/para a RTU, lidam com erros de comunicação e novas tentativas, varredura programada das RTUs. A MTU lê e varre as informações das interfaces de comunicação e verifica se ocorreu desvio do ponto de ajuste na variável de processo e produz ação de controle ou status de alarme. Também é através da unidade central que os comandos de operação são transferidos para as unidades remotas.


Em um sistema SCADA a MTU pode ser uma sala de operação com diversas estações de operador compartilhadas num mesmo nível de controle ou uma IHM local instalada em um determinado painel.


Rede de comunicação:


As UTRs no campo são conectadas entre si por meio de uma rede de controladores. Cada RTU possui um endereço único e a rede é conectada a um dispositivo tipo modem, hoje em dia, são sempre redes de switchy formando anéis ou estrelas. A transmissão de dados de RTUs para MTU pode ser por meio de conexão elétrica ou óptica muito embora existam conexões via wireless e IR.


Poderia ficar dias discutindo conceitualmente o que é um sistema SCADA mas em linhas gerais o conceito de SCADA é um sistema que se estende desde a aquisição do dado no campo até a apresentação do dado na tela, tudo isso é SCADA.


Espero que a explicação tenha sido útil, muitas vezes me deparo com debates longos e filosóficos sobre o tema seria interessante que todas as pessoas que atuam na automação tivesse firmemente definido os conceitos em sua mente.


segunda-feira, 1 de novembro de 2021

O que é Redundância em PLC's ?

 Controlar um processo através de um PLC é basicamente receber um conjunto de informações e tomar ações automáticas ou manuais sobre elas de modo a manter um processo em execução.

Nos processos de controle, redundância significa fornecer uma caminho alternativo de processo numa condição de falha de uma de suas partes. Isso se traduz em ter mais de uma alternativa pelo qual o caminho entre: a informação chegar no PLC, o tratamento dessa informação e a externalização do controle do processo.


A necessidade da redundância vem de cada indústria específica. Cada indústria tem sua própria definição de confiabilidade. Alguns sistemas de automação exigem redundância de PLC para manter as pessoas e equipamentos seguros reduzindo o tempo de indisponibilidade de um processo específico controlado pelo PLC.


Por vezes um pequeno investimento extra em redundância pode reduzir os danos e inconveniências quando um controlador falha.


No passado a falha de controladores era uma constância. Um equipamento eletrônico sensível que muitas vezes era submetido a atmosferas industriais com humidade, calor, sais pesados, poeira… Não era incomum que um PLC parasse de funcionar sem nenhuma ação evidente de avaria.


Um caminho foi a climatização dos painéis e a construção de salas de painéis exclusivas. Uma triste constatação é que sempre que um PLC para por qualquer motivo é sempre possível alegar que se deu pelo estresse do local onde estava submetido. Isso é um tema particular que não vem ao caso nessa discussão sobre redundância.


Trabalhei em uma indústria de plástico que fazia garras PET. Quando uma máquina injetora parava de funcionar era uma correria tremenda para tirar todo o plástico ainda mole da máquina antes que se solidificasse, principalmente se fossem garras transparentes em que o plástico se cristaliza.


Também trabalhei em outros locais onde a redundância foi implementada e não era necessária, o que me deu um trabalho adicional de programação e após 4 anos de funcionamento (num retorno para manutenção) percebi que a unidade de backup nunca sequer tinha entrado em funcionamento.


O fato é que a redundância no controle veio como uma alternativa para aumentar a disponibilidade e confiabilidade de processos industriais principalmente para atender os seguintes casos:


Automação em processos contínuos - Processamento de alimentos, linhas de montagem de produtos, indústria de papel e celulose. Nestes casos, a paralisação em uma seção pode levar a gargalo em outros e perda de produto inacabado em toda a linha de montagem.

Um caso interessante de processo contínuo é a indústria de energia: O ONS - Operador Nacional do Sistema Elétrico solicita que todo o sistema de proteção seja redundante. Você poderia indagar, mas o controle não, de fato, o ONS solicita que a apenas a parte de proteção seja completamente redundante assim no Brasil todo o sistema de transmissão de energia é redundante.

A proteção é um controle exclusivo com a finalidade de atuar exclusivamente isolando uma falha, por isso podemos classificá-la como um determinado tipo de  controle que independe da ação humana.


Processamento de lotes: Industriais como a automobilística utiliza redundância para suas linhas de montagem como são lotes e lotes em uma linha de série a paralisação de um micro processo causa a paralisação de uma linha inteira o que já é o suficiente para se justificar a redundância.

Os antigos sistemas de telefonia também são redundantes, duas unidades processam toda vez que você digita um número de telefone, as duas estabelecem a rota telefônica para o usuário na outra ponta e se houver uma discrepância entre as duas há um arbitrário que verifica quem está com problema e o coloca fora de funcionamento.


Indústrias Críticas: O controle de mineração, nuclear e gás não pode interferir na operação e no monitoramento da segurança. Um sistema de controle de backup completo requer 100% de tempo de atividade para evitar incidentes fatais e caros.


Veja que para o caso da indústria nuclear dois caminhos não atendem a necessidades de disponibilidade e falha, às vezes mais caminhos são necessários para garantir a confiabilidade, redundâncias triplas e quadruplas.



Mas afinal, o que pode ser redundante, como construir um sistema redundante? Existem diversas opções de redundância em controlador, vamos discutir algumas delas:


Redundância da CPU:


Se a CPU falhar, a unidade de espera mantém a planta funcionado pela outra CPU (chamada de alternada ou alternativa ou ainda slave/secundary)



Nos tempos atuais essa é a forma mais medíocre de redundância. A indústria se adapta às solicitações, hoje muitos PLC’s são concebidos de forma a ter uma redundância de CPU nativamente em seus hardwares de tal forma que quando uma empresa solicita uma arquitetura redundante comumente são apresentados a esta solução com duas CPU’s.


Acontece que hoje em dia a taxa de falha das CPU’s é muito baixa a ponto de tornar qualquer solução de redundância exclusiva de CPU um item praticamente proforma sem se traduzir em um resultado ou ganho expressivo. 


Ter duas CPU’s introduz uma questão: O que é entendido com a falha de causa comutação de CPU? Afinal, a comutação deve ocorrer apenas no momento em que a CPU efetivamente falha e geralmente quem determina a necessidade de comutação é através de algum diagnóstico interno do equipamento que precisa ser tratado.


Redundância de fornecimento de energia:


A redundância de fontes é outro item indispensável no kit redundância dos fabricantes. Ter duas fontes e o PLC poder ser alimentado por qualquer uma é uma função essencial presente em praticamente todas as famílias de PLC de médio e grande porte. 


Os sistemas de alimentação ininterrupta em 24Vcc , 125Vcc ou 220Vcc são constantemente redundantes, por alimentar diversos sistemas é sempre passível de manutenção é de entendimento comum que todos os dispositivos precisam ter duas alimentações.


Até mesmo quando o PLC é alimentado em uma fonte CA, ter duas fontes de alimentação CA/CC é uma boa alternativa para aumentar a confiabilidade. Não é tão incomum ver uma fonte conversadora se danificando pelo tempo de funcionamento. 



Comunicação:


Hoje nenhum sistema complexo foge da temível comunicação com outros dispositivos seja por um sistema supervisório ou para um simples multimedidor, o PLC tem a função mínima de transceptor de dados recebendo via algum protocolo de comunicação dados em forma de comunicação com outros dispositivos.


Ter múltiplos canais de comunicação é uma estratégia segura para manter o sistema confiável. Naturalmente a redundância no canal de comunicação têm suas próprias sub-redundâncias, ou seja, existem diversas formas de se tratar um canal redundante de comunicação bem como de implementar. Talvez trate desse tema em outro artigo exclusivo sobre isso.


I/O:


A redundância de entradas ocorre quando um sinal proveniente do campo é recebido através de duas entradas distintas e o mesmo pode ser aplicado para saídas digitais.



Neste caso,  seria a plenitude de um sistema de controle redundante um sinal é recebido por duas entradas processado em um conjunto de CPU’s redundantes alimentado por fontes redundantes e devolvido através de saídas redundantes para o processo.


Sem dúvida muito mais oneroso que as soluções anteriores.


* aqui cabe um pequeno adendo. Estamos tratando apenas de PLC, é possível que um processo possa ter dois sensores distintos instalados no mesmo local alimentado entradas distintas e neste caso seria uma redundância de instrumento.





Evidente que o tema da redundância não acaba por aqui. 


Numa breve discussão é bem nítido que todos os exemplos mostrados anteriormente se trata de um único conjunto sólido o que nos remete ao fato que sempre haverá uma possibilidade física de dano em um dispositivo modo comum, como por exemplo um rack que distribui a alimentação redundante ou que gerencia as CPU’s redundantes. Por isso existem outros tipos de redundância para evitar exatamente o “modo comum de falha”, vejamos:


Operação Independente


Novamente, dois PLCs são usados por vez, mas cada um opera separadamente, e as entradas e saídas são divididas entre os dois processadores igualmente (50/50). Se um PLC falhar (juntamente com seus sistemas de backup interno), apenas metade da capacidade será perdida em vez da carga total. Este é o sistema de controlador redundante mais fácil de implementar, mas requer linhas de montagem duplicadas, controladores, sensores e atuadores.



Modo sombra (Shadow mode)


Dois PLCs idênticos compartilham as mesmas entradas e saídas e executam o mesmo software. O primeiro serve como o principal, enquanto o segundo serve como um backup. Se a segunda unidade não receber um sinal de vida do primeiro, a unidade de backup assume o controle do sistema de automação, garantindo o funcionamento ininterrupto. Estes requerem um pouco mais de design, e um circuito de arbitragem para os sensores e atuadores para evitar inconsistências.



Modo de divisão (operação dependente)


Geralmente usado em ambiente bancário e telefônico, os dois PLC’s ou microcomputadores compartilham as mesmas entradas e tomam decisões independentes antes de definir uma saída externalizada (como entregar o dinheiro no caixa eletrônico). Se uma incompatibilidade for observada, uma resposta especial do sistema será aplicada. Esse tipo de sistemas de automação a intervenção apropriada pode ser um simples relatório ou desaceleração do processo para intervenção de um arbitrário humano. 


Votação


Esse é um dos sistemas que realmente é muito difícil de ver por aí, mas é utilizado principalmente para descarte de peças cerâmicas ou avaliar a qualidade de lotes de fabricação, em controle de qualidade no geral. 

Um número ímpar de sistemas de controle independentes tomam decisões autônomas e uma votação é postada antes de uma decisão ser tomada (regra da maioria). Esses sistemas são os mais caros de construir porque exigem sistemas de controle redundantes, que podem ser muito volumosos e caros para algumas aplicações. E a programação do PLC requer um design mais elaborado, por isso é quando se deseja afinar o processo mesmo.


Existe ainda muito o que se falar sobre redundância mas numa visão simplista estes são os tipos mais conhecidos de redundância. 

Para mim, hoje, um sistema redundante precisa de um desenho que vai além da escolha de um hardware precisa de uma metodologia que envolve a escolha da solução, a escolha da instrumentação e a disponibilidade do processo que muitas vezes é uma escolha arbitrária.