Disponibilidade e Diagnóstico em Controladores

54 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
54
No SlideShare
0
A partir de incorporações
0
Número de incorporações
4
Ações
Compartilhamentos
0
Downloads
0
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Disponibilidade e Diagnóstico em Controladores

  1. 1. DISPONIBILIDADE E DIAGNÓSTICO EM CONTROLADORES Rodrigo Aznar Mendes rodrigomendes@smar.com.br Abstract This work presents what is currently available in the specification of the industrial network standards concerned to availability and related diagnostics. Also based on the practical experience this work provides a mapping of the scenarios and concepts not explicit in the specifications. This combined approach serves as a guide for understanding and criterious evaluation of redundant systems and controllers. Resumo Este trabalho apresenta o que existe de mais completo na normatização dos padrões de rede industrial no que se refere a disponibilidade e o diagnóstico relacionado a disponibilidade. Com base também em experiência prática é realizado um mapeamento de cenários e conceitos não explícitos nas normatizações visando no conjunto fornecer um guia para o entendimento e avaliação criteriosa de sistemas e controladores redundantes. Palavras-chave: Controladores, Disponibilidade, Tolerância a falhas, Redundância de equipamentos, Diagnóstico, SNMP, Sistemas inteligentes, Avaliação de sistemas. 1. INTRODUÇÃO Ainda que o tema disponibilidade em automação industrial seja de grande relevância, é escassa a literatura abordando em detalhes o uso de redundância como recurso-chave para obter melhor disponibilidade de sistemas. No que diz respeito a como deve ser implementada e como deve funcionar a redundância nos equipamentos, há também muitos pontos abertos na normatização dos padrões de rede industrial. Vale lembrar que falhas ou paradas não programadas na indústria podem significar desastres em meio a um processo produtivo, causando grandes perdas econômicas e até ameaçando vidas humanas. Estes fatores em conjunto motivaram a elaboração deste trabalho que visa em primeira instância, com base na normatização da Fieldbus FoundationTM (FF, 2005), trazer em detalhes de que forma a redundância de equipamentos e de rede deve ser implementada para garantir efetivamente uma melhor disponibilidade do sistema de automação. De uma forma geral os conceitos e benefícios contidos nesta especificação podem ser estendidos como referências para a avaliação de equipamentos e sistemas baseados em outros padrões ou tecnologias. Busca-se também, baseado na experiência prática da área de pesquisa e desenvolvimento, apontar cenários menos explícitos porém muitas vezes fundamentais para uma avaliação mais criteriosa de controladores e sistemas no que diz respeito as características de disponibilidade e diagnóstico. A abordagem adotada aqui pretende apresentar os detalhes de funcionamento da redundância de equipamentos e de rede, bem como os diagnósticos relacionados, porém da perspectiva do usuário final de equipamentos e sistemas, ou seja, o engenheiro de automação da planta. Este trabalho possui foco nos controladores baseados em padrões de redes industriais como Profibus, Foundation Fieldbus HSE / H1, ControlNet, EtherNet/IP, etc. Ou seja, faz sentido discutir soluções completas de disponibilidade e diagnóstico considerando padrões reconhecidos, abertos e com alguma capacidade de diagnóstico embutida. A seção 2 apresenta os conceitos e definições relativos a redundância de controladores conforme a especificação da Fieldbus FoundationTM (FF, 2005). A seção 3 apresenta os conceitos e definições relativos a redundância de rede conforme a mesma especificação. A seção 4 trata dos aspectos de diagnóstico particularmente para o caso de sistemas redundantes. Finalmente, a seção 5 apresenta um guia prático e criterioso para avaliação de controladores e sistemas redundantes. Como glossário para os termos e conceitos aqui tratados referir-se ao Glossário Fieldbus/Automação (FF, 2008). 1
  2. 2. 2. REDUNDÂNCIA DE EQUIPAMENTOS 2.1. Tolerância à falhas e redundância A Figura 1 abaixo ilustra no contexto mais amplo de tolerância à falhas, como há uma gama extensa de estratégias de redundância (SALUJA, 2007; SHOOMAN, 2002). Figura 1. Diagrama com resumo das técnicas para tolerância à falhas Algumas destas estratégias podem ser aplicadas em conjunto para aumentar a confiabilidade e robustez do sistema em um contexto mais amplo que engloba hardware, software e funcionalidades. A título de esclarecimento, as técnicas de redundância de informação, de tempo e de software estão geralmente no escopo do projeto dos equipamentos em si (geralmente no contexto do projeto de software) e por isto não estão diretamente ligadas ao projeto de uma planta pelo engenheiro de automação. Estão sim indiretamente ligadas ao projeto de uma planta na medida em que equipamentos que façam uso de alguma destas técnicas irão tornar explícito o uso destas técnicas para evidenciar maior confiabilidade e robustez. Assim este trabalho terá foco na redundância de hardware, pois esta é a técnica diretamente ligada a fase de projeto de uma planta pelo engenheiro de automação. A redundância de hardware ou redundância de equipamentos visa melhorar a tolerância à falhas de hardware que são falhas que naturalmente ocorrem no ambiente físico de uma planta. Dentre todas as estratégias de redundância de hardware, podemos destacar a estratégia Hot Standby em razão dos benefícios abaixo: − Secundário opera sincronizado com o equipamento Primário; − Secundário permanece em estado pronto para assumir a operação como Primário, caso o Primário sofra uma falha; − Detecção automática de falhas; − Fator importante: menor tempo para troca de função (switch over), sem sobressaltos e sem que seja necessária a intervenção do usuário; − Aplicação típica: plantas industriais (switch over sem sobressaltos possibilitando operação ininterrupta). 2.2. Normatização Fieldbus FoundationTM HSE para redundância de equipamento A especificação da Fieldbus FoundationTM para redundância (FF, 2005) define três classes possíveis de redundância de equipamento, D-1, D-2 e D-3, baseadas em diferentes capacidades para 2
  3. 3. sincronismo, detecção de falhas e recuperação. A classe D-3 vem a ser a mais completa já que possui as características abaixo, todas de responsabilidade do próprio par controlador: − Configurações continuamente sincronizadas (controladores fortemente acoplados); − Detecção autônoma de falhas; − Switch over/recuperação autônoma após a ocorrência de uma falha; − Primário e Secundário funcionam operacionalmente como um único equipamento. Já as classes D-1 e D-2 resumidamente são modelos limitados de redundância, onde não há sincronismo entre Primário e Secundário e a redundância depende totalmente de ações através do configurador e/ou usuário. A classe D-3 contém algumas definições de operação para o conjunto configurador-controlador sendo em sua essência muito similar a estratégia de redundância Hot Standby amplamente conhecida. Algumas definições da classe D-3 são particulares da normatização (FF, 2005) e se estendem além daquilo que é normalmente retratado com a estratégia Hot Standby. Este trabalho não pretende apresentar os detalhes de como tais definições ou facilidades são implementadas nos equipamentos, mas sim apresentar suas vantagens. A seguir as definições em questão. Transparência Operacional Por esta capacidade presente somente na classe D-3, durante todo o tempo de operação, o par controlador é visto como um único equipamento pelo configurador. Na prática o configurador, também designado na norma como Host ou hospedeiro terá visibilidade apenas do controlador que estiver naquele momento com a função de Primário. Após a ocorrência de um switch over, o configurador passará automaticamente a ter visibilidade do novo Primário. Todas as ações de configuração disparadas do configurador para o par controlador terão como destino apenas o atual controlador Primário. Será de responsabilidade do par controlador sincronizar sua configuração bem como as variáveis dinâmicas do processo, o que deverá ocorrer através de um canal de sincronismo proprietário entre Primário e Secundário. Assim, ações como comissionamento, descomissionamento, download de configuração e parametrizações afetam ambos os controladores (Primário e Secundário) de maneira transparente para o configurador e para o usuário. Esta facilidade de uso por parte do configurador e do usuário é designada na normatização como Transparência Operacional. Visibilidade de diagnóstico Em contraposição a transparência operacional, para efeito de diagnóstico, manutenção e gerenciamento de ativos deseja-se ter acesso a dados específicos de cada um dos controladores de um par controlador. Tal capacidade é também mencionada na normatização de redundância (FF, 2005) com a designação de visibilidade de diagnóstico. A normatização não define porém um padrão para como os fabricantes de equipamento devem implementar tal característica. Na seção 4 veremos os atributos esperados para o contexto de diagnóstico e algumas possibilidades quanto à forma com que estes atributos podem ser disponibilizados nos equipamentos. A redundância de rede é um conceito independente da redundância de equipamentos e será visto na seção seguinte. 3. REDUNDÂNCIA DE REDE Os padrões de rede industrial baseados em Ethernet tornam-se cada vez mais difundidos e confiáveis no meio industrial muito em função de equipamentos de automação e de rede projetados pensando nas condições e nas criticidades do meio industrial. Podemos afirmar que a Ethernet no chão de fábrica veio para ficar apenas por dois fatos: − Diversidade de padrões baseados em Ethernet: ControlNet, EtherNet/IP, Profinet IO, Ethernet PowerLink, EtherCat, Foundation HSE, etc; − Permite a integração do chão de fábrica aos sistemas de gestão do negócio. Especificamente sobre o tema Ethernet Industrial há uma extensa gama de trabalhos enfocando os mais diversos aspectos, notadamente determinismo, segurança e disponibilidade (MADREN, 2004). Para alta disponibilidade requer-se também redundância de meio físico (ou de rede). Sistemas que possuem duas portas Ethernet por controlador permitem o projeto de uma rede de automação totalmente redundante. O sistema como um todo também deve suportar a redundância de rede, de forma que as estações de trabalho realizem as ações de configuração, operação, supervisão e manutenção tirando proveito da disponibilidade que a redundância de rede confere ao sistema. Controladores dotados de redundância de portas Ethernet estão muito à frente dos que não possuem esta característica, pois somente desta forma é possível ter tolerância à falhas no caminho 3
  4. 4. entre os controladores e os equipamentos de rede. Redes de automação com switches redundantes em topologia tipo anel e recursos como STP (Spanning Tree Protocol) conferem excelente tolerância para falhas que ocorram no anel (ANSI/IEEE, 2004), mas sendo o controlador não dotado de redundância de porta Ethernet, haverá sempre um calcanhar de aquiles para o sistema como um todo. Ocorre que dado o tamanho da planta e da rede de automação nem sempre a rede é grande o suficiente para justificar o uso de uma rede de switches em anel. Neste caso, mais uma vez, controladores com duas portas ethernet apresentam grande vantagem por poder atender de forma totalmente redundante até mesmo pequenas topologias de rede com o tipo estrela ou barramento, sem necessitar de muitos equipamentos de rede e ainda assim assegurando boa disponibilidade. Ou seja, ter redundância de rede significa ter redundância de todas as operações que ocorrem através desta rede. No caso específico de uma solução baseada em FF HSE, isto significa ter redundância e por conseqüência maior disponibilidade para as seguintes operações: − Todas as operações solicitadas pelas estações de engenharia, operação e manutenção. Ex.: comissionamento, descomissionamento, download de configuração, parametrizações e supervisão; − Links HSE de controle para outros controladores; − Supervisão/controle por Modbus (integração com sistemas legados). No que diz respeito à rede Ethernet, dentro do contexto de tolerância a falhas e robustez requeridos em ambiente industrial devem ser guardados os seguintes cuidados: − Projetar a rede Ethernet de automação separada fisicamente da rede local corporativa; − Utilizar switches industriais (garantem um melhor determinismo para a rede); − Switches devem ser gerenciáveis e com suporte aos protocolos SNMP e SNTP; − Cálculo da disponibilidade e/ou tempo de parada esperado para todo o sistema com as possíveis topologias de rede desejadas; O cálculo da disponibilidade e/ou tempo de parada pode ser feito com base no MTBF e MTTR divulgado para cada componente de hardware. Há muitas referências de como efetuar este cálculo, entre elas a da EventHelix (EVENTHELIX, 2008). É importante lembrar a relação entre MTTR (Mean Time To Repair) em horas e os valores de disponibilidade muitas vezes mencionados, pois este último nem sempre é entendido devido as diferenças pequenas na parte decimal não serem auto-explicativas. A Figura 2 traz esta relação (CISCO SYSTEMS, 2007). Disponibilidade Defeitos por milhão de eventos Tempo de parada por ano 99,9000% 1000 8 horas, 46 minutos. 99,9500% 500 4 horas, 23 minutos. 99,9900% 100 53 minutos. 99,9990% 10 5 minutos. 99,9999% 1 30 segundos. Figura 2. Relação entre disponibilidade e tempo de parada É necessário avaliar se a infraestrutura de softwares do sistema suporta efetivamente o tratamento de duas placas de rede Ethernet. Um sistema baseado em OPC (OLE for Process Control) e seu aplicativo configurador devem saber tratar com duas placas de rede as diversas ações de supervisão e de configuração de forma transparente tal que o operador não tenha que se preocupar com qual dos controladores é o atual Primário ou por qual das redes está se dando a comunicação. Ou seja, a transparência operacional depende não só dos controladores, mas do sistema como um todo. Para tanto, é necessário que os fabricantes do sistema tenham tido este cuidado durante o projeto da característica de redundância. Na prática a transparência operacional para o sistema como um todo só é possível se todos os componentes estiverem conforme alguma normatização comum que estabeleça de que forma isto deve ser implementado. Se considerarmos um sistema com componentes de diferentes fabricantes, a conformidade com uma normatização comum torna-se ainda mais importante. Padrões de rede industrial que não estabeleçam um padrão comum para o aspecto transparência operacional deixam em aberto como vão garantir esta importante característica, até mesmo para o caso da planta ser projetada com todos os componentes do mesmo fabricante. 4
  5. 5. 4. VISIBILIDADE DE DIAGNÓSTICO EM SISTEMAS REDUNDANTES Abaixo apresentamos alguns dos tipos de atributos mais úteis e dos quais se deseja conhecer o valor especificamente no Primário e Secundário: − Versão de firmware; − Número de série; − Nível de retenção da bateria; − Estatísticas de eventos e falhas; − Atributos de status da redundância; − Alarmes / indicativos de más condições; − Indicativos de falhas nas interfaces; Não há um padrão para de que forma devem ser disponibilizados os atributos específicos para visibilidade de diagnóstico. A seguir são apresentadas duas opções interessantes cada vez mais utilizadas em sistemas embarcados com interface Ethernet: 4.1. Webserver O recurso de webserver é uma característica cada vez mais comum em sistemas embarcados com interface Ethernet. É baseado em um servidor de páginas web embutido no equipamento. O acesso é feito através de qualquer navegador internet utilizando o IP do equipamento em questão (Figura 3). Figura 3. Acesso ao webserver de um dos controladores de um par redundante Desta forma é possível, por exemplo, acessar somente o equipamento Primário ou o Secundário. Suas principais vantagens são a possibilidade de se ter um ambiente amigável baseado no conceito de navegação da internet. É bastante útil para consultas rápidas que o usuário do sistema queira efetuar. 4.2. SNMP O SNMP (Simple Network Management Protocol) é um protocolo que faz parte do conjunto de protocolos TCP/IP (THE INTERNET ENGINEERING TASK FORCE, 2008) e já está disponível na grande maioria dos computadores e em todos os dispositivos de rede Ethernet gerenciáveis. Há equipamentos e controladores baseados em Ethernet que trazem embutido o protocolo SNMP como alternativa para diagnóstico, o que pode incluir até mesmo alarmes e eventos 5
  6. 6. específicos para Primário e Secundário. Alarmes ou eventos são facilitados por recursos que a normatização SNMP define como traps. Resumidamente, o SNMP se baseia em MIBs (Management Information Base ou base de dados gerenciável). Estas MIBs são implementadas nos equipamentos e em geral mapeiam importantes atributos dos equipamentos de uma forma padronizada. É possível a definição de objetos com permissão de escrita nas MIBs. Em controladores redundantes, as MIBs SNMP não são sincronizadas entre Primário e Secundário, ao contrário do que se deseja para as bases de dados de aplicação como blocos funcionais e lógicas Ladder, por exemplo. Por este motivo, por SNMP é possível ter acesso a atributos de diagnóstico específicos de cada um dos controladores que formam um par redundante. Também, pelas características oferecidas pelos traps e objetos das MIBs com permissão de escrita, é possível com o uso de SNMP integrar controladores a sistemas de gerenciamento de ativos. Esta integração permite o tratamento individual (para cada um dos controladores que formam um par redundante) com os seguintes fins: − Diagnóstico de falhas e más condições; − Configurações/manutenção para gerenciamento do ativo; − Monitoramento de alarmes e eventos. Fabricantes atentos ao potencial do SNMP para diagnóstico em sistemas redundantes podem implementar a abstração do SNMP para padrões conhecidos em automação, como o OPC. Abaixo (Figura 4) uma seqüência de telas de supervisório que fazem uso das seguintes facilidades: − OPC Server implementando uma interface de abstração SNMP/supervisório. Para tanto o OPC Server deve conhecer a MIBs exatamente como descrita e implementada nos controladores; − Controladores com suporte ao SNMP e implementação de MIBs que mapeiam os atributos interessantes para efeito de diagnóstico/manutenção; − Telas de supervisório implementadas visando diferentes visões dos atributos ou equipamentos com evidência para alarmes específicos do Primário e/ou Secundário; Figura 4. Diagnóstico de controladores redundantes através de SNMP 6
  7. 7. Por fim, com o uso do recurso snmpwalk qualquer aplicativo de terceiro com suporte a SNMP pode navegar na MIB dos equipamentos e, sem conhecimento prévio de como a MIB SNMP do equipamento está organizada, terá acesso a importantes atributos de diagnóstico. Sendo cada vez mais comum equipamentos de automação baseados em Ethernet, o SNMP torna-se de fato uma excelente alternativa para diagnóstico, especialmente para equipamentos redundantes com a facilitação da visibilidade de diagnóstico. Por fim, permite também o diagnóstico e gerenciamento dos componentes de rede como switches gerenciáveis. 5. AVALIAÇÃO DE CONTROLADORES E SISTEMAS REDUNDANTES Em um sistema de alta disponibilidade, não apenas todos os equipamentos devem ser redundantes, mas a arquitetura do sistema como um todo deve ser projetada como redundante. Um sistema efetivamente redundante deve possuir redundância implementada em diversos níveis de seus componentes de hardware e software, oferecendo tolerância à falhas, alta disponibilidade e segurança (Figura 5). Figura 5. Arquitetura de um sistema com redundância em todos os níveis A seguir é apresentada uma tabela com os itens a serem verificados durante a avaliação de um sistema ou controlador redundante. A maioria dos dados devem ser disponibilizados pelo fabricante ou fornecedor da solução. Item Descrição Arquitetura do sistema com redundância em todos os níveis. Deve-se ter redundância na maior quantidade possível de componentes: estações de trabalho, placas de rede das estações, redundância da rede e dos componentes da rede, controladores, duas portas de rede por controlador, fontes de alimentação, redundância de canais dedicados no controlador (Ex.: FF H1, Profibus PA, etc). Aplicativos/softwares com suporte a redundância. Os aplicativos da solução de automação devem possuir tratamento especial para trabalhar com um arquitetura redundante. O fabricante deve evidenciar de que forma os aplicativos permitem e facilitam o uso dos aplicativos em uma arquitetura redundante. 7
  8. 8. Tempo para troca de função Secundário para Primário (switch over) O mesmo deve ser divulgado pelo fabricante sendo que o seu valor torna-se mais crítico para aplicações de controle discreto ou do tipo batelada com ciclos de execução da ordem de ms, onde requer-se um tempo de switch over também da ordem ms. Aplicações de controle contínuo (ou processo) em geral possuem ciclos a partir de algumas dezenas de ms, onde o tempo de switch over torna-se menos crítico. Taxa de sincronismo Taxa de sincronismo é a velocidade com que as bases de dados dinâmicas do Secundário são atualizadas pelo Primário. Quanto menor for o ciclo de execução da aplicação tanto maior deverá ser a taxa de sincronismo para garantir que o Secundário esteja sempre em fase com o último ciclo executado. Falhas que levam a uma troca de função (switch over) Devem ser detalhados quais são os tipos de falhas que uma vez detectadas, levam a um switch over e são assim totalmente cobertas pela redundância do controlador. Ex.: Falhas gerais Quando todo um controlador falha: - Falha de Hardware - Falha na alimentação - Remoção do controlador do rack Falhas de má condição Quando uma das interfaces de um controlador Primário falha: - Falha de todos os cabos Ethernet diretamente conectados ao Primário. - Falha em um canal H1 (hardware ou cabos) do Primário. - Falha na comunicação Modbus (hardware ou cabos; caso esteja operando como mestre). - Falha de todos os links HSE do Primário. Redundância para todas as configurações e funcionalidades dos controladores Todas as configurações e funcionalidades dos controladores devem possuir tratamento especial para que o sistema opere de forma efetivamente redundante e transparente. Exemplo de funcionalidades de um controlador que devem possuir redundância: - Blocos Funcionais - Bloco Funcional Flexível (FFB / Lógica Ladder) - Acesso a pontos Entrada/Saída convencionais - Links de controle H1 e HSE Foundation FieldbusTM - Link Active Scheduler (LAS ou o escalonador Ativo da comunicação nos canais Foundation Fieldbus H1) - Gateway Modbus ↔ 4 portas Foundation Fieldbus H1 Possibilidade de controladores em racks isolados Empregando controladores e fontes redundantes em racks isolados fisicamente, evita-se fontes comuns de falha. Desta forma as fontes naturais de falha poderão afetar somente uma das partes do sistema redundante garantindo a disponibilidade e segurança do processo. Estado de segurança em caso de falha ocorrida antes do fim do sincronismo de configuração Caso ocorra uma falha geral no Primário antes do sincronismo de configuração ter sido completado é recomendável que o Secundário não assuma como Primário, mantendo a mesma função. Isto representa um estado de segurança já que o Secundário não possuindo configuração válida poderia afetar a correta partida da planta. 8
  9. 9. Redundância de canal de sincronismo Um par de controladores que possua redundância do canal de sincronismo, significa maior disponibilidade da própria redundância do equipamento. Um sistema que não possua tal característica, na prática possuirá um calcanhar de aquiles, pois ocorrendo uma falha especificamente neste canal, o sistema passará a não ter mais a redundância disponível, ainda que o sistema permaneça operacional para todas as suas demais tarefas. Neste caso, ocorrendo uma segunda falha no controlador Primário, qualquer que seja, não será possível que o Secundário assuma com segurança as tarefas relativas ao processo, já que este estará em estado não sincronizado. Indicação de falha de cabo de sincronismo Controladores com redundância de canal de sincronismo devem indicar a ocorrência de uma falha que ocorra em algum dos caminhos, permitindo a manutenção proativa. Transparência Operacional O par controlador deve ser visto como um único equipamento pelos aplicativos de configuração e supervisão de tal forma que o usuário tenha os benefícios da redundância mas não tenha que tomar cuidados adicionais com o aspecto redundância durante a operação do sistema. O fornecedor do sistema deve evidenciar de que forma os seus diferentes componentes garantem a transparência operacional. Visibilidade de diagnóstico Primário e Secundário devem ter acesso individual para fins de diagnóstico, manutenção e gerenciamento de ativo. O fornecedor do sistema deve evidenciar de que forma esta característica é disponibilizada e quais são os atributos de diagnóstico, manutenção e gerenciamento de ativo disponíveis nos controladores. Indicação de falhas nas interfaces mesmo para o Secundário (manutenção proativa) Os diferentes tipos de falhas, como falhas nas interfaces, devem ser sinalizadas mesmo que ocorram no Secundário, isto permite manutenção proativa, assegurando a manutenção da disponibilidade da própria redundância. Visibilidade plena do estado e dos atributos da redundância As informações de estado da redundância devem poder ser monitoradas através de alguma interface padrão. Ex.: parâmetros de um bloco funcional (supervisão por OPC) ou mesmo através de uma MIB SNMP. Indicação dos estados principais da redundância no frontal dos controladores Os controladores devem possuir indicação visual no frontal (ex.: LED) para sinalizar sobretudo ao operador em que estado de redundância o par controlador se encontra. Tal indicação garante que ações de teste / manutenção sejam feitas corretamente e com segurança. Facilidade de uso - Aplicativos Um sistema bem projetado para operação efetivamente completa em redundância notadamente deverá ser configurado e operado tão facilmente quanto um sistema não redundante. Facilidade de uso - Definição de funções automática durante a inicialização Os controladores devem definir sua função (Primário ou Secundário) de forma autônoma durante a inicialização, não sendo necessária nenhuma ação do usuário. Facilidade de uso – Cenário: substituição Não deve ser necessário novo download de 9
  10. 10. de um módulo controlador com falha configuração ou intervenção do usuário. O novo controlador inserido deve ser automaticamente reconhecido e sincronizado, recebendo toda a configuração e mesmo parametrizações efetuadas enquanto o controlador em operação estava sem redundância. Facilidade de uso – Cenário: adicionando controladores redundantes a um sistema não-redundante Um sistema não redundante deve oferecer a facilidade de permitir posteriormente a adição de controladores redundantes sem que seja necessária a parada da planta. Facilidade de uso – Cenário: atualização do firmware sem interrupção do processo Deve ser possível realizar uma atualização dos controladores para versões mais atuais de firmware que agreguem melhorias ou novas características sem que seja necessária a interrupção do processo. O processo deve ser seguro, consistindo na atualização de um controlador do par redundante por vez. Partindo do conceito de disponibilidade há um conceito mais amplo que é o de tolerância a falhas e neste aspecto muitos outros fatores merecem cuidados. Listamos aqui os principais, a título de completar este guia de avaliação da disponibilidade em sistemas de automação: − Confiabilidade dos cabos – pode ser avaliado através do MTBF; − Confiabilidade dos equipamentos – pode ser avaliado através do MTBF; − Específico do padrão de rede em questão: − particularidades na montagem dos cabos; − topologia das redes industriais, seja no nível de equipamentos de campo, ou no nível de controladores/bridges/gateways; − Desenvolver estratégias de controle utilizando recursos de bypass ou fail-safe em relação a possíveis falhas; − Controle distribuído – confere maior isolação de falhas. Especificamente sobre os itens “Visibilidade plena do estado e dos atributos da redundância” e “Indicação de falhas nas interfaces mesmo para o Secundário (manutenção proativa)” as Figuras 6 e 7 a seguir exemplificam que tipos de informações são diretamente ligadas ao estado da redundância do par controlador. Tais parâmetros podem ser disponibilizados através de bloco funcional (supervisão via OPC Server) ou através de uma MIB SNMP (supervisão via SNMP-OPC Server). PARÂMETRO FAIXA VÁLIDA/OPÇÕES DESCRIÇÃO RED_PRIMARY_SN 0 ~ 65535 Indica o número serial do controlador Primário. RED_SECONDARY_SN 0 ~ 65535 Indica o número serial do controlador Secundário. 1
  11. 11. PARÂMETRO FAIXA VÁLIDA/OPÇÕES DESCRIÇÃO RED_SYNC_STATUS 0: Not defined 1: Stand Alone 2: Synchronizing 3: Updating Secondary 4: Synchronized 5: WARNING: Role Conflict 6: WARNING: Sync Cable Fail 7: WARNING: Updating Secondary Fail Indica o estado de sincronismo do par controlador. 0: Valor default logo após inicialização. 1: Operação não-redundante (estado Stand Alone). 2: Verificando configuração para sincronizar. 3: Primário transferindo configuração para o Secundário. 4: Sincronizado. Primário atualiza o Secundário continuamente com as variáveis dinâmicas de processo. 5: Conflito de função. Não foi possível resolver de maneira autônoma a função (Primário/Secundário). 6: Falha em todos os cabos de sincronismo (redundância indisponível). 7: Falha do Primário antes do sincronismo ter sido completado (redundância indisponível). RED_PRIMARY_BAD_CONDITIONS RED_SECONDARY_BAD_CONDITIONS Bit 0: Modbus 1: H1-1 2: H1-2 3: H1-3 4: H1-4 5: Live List 6: Eth1 7: HSE link 8: Eth2 9: Serial Sync Cable 10: Unable to Sync Más condições no controlador Primário / Secundário. Figura 6. Atributos da redundância de um par de controladores Figura 7. Detalhamento dos atributos de más condições de um par controlador (Bit- String) 1
  12. 12. 6. CONCLUSÕES Neste trabalho foi apresentado uma coleção de conceitos, cenários e outros detalhes fundamentados na normatização Fieldbus FoundationTM mas também pautados em experiência prática. O intuito é servir de guia para o projeto de sistemas com boa disponibilidade e bons recursos de diagnóstico. No momento de realizar uma atualização de tecnologia em um planta, uma fase criteriosa de avaliação e comparação de características e benefícios significa valorizar os investimentos e pode evitar muitos problemas no futuro. Finalmente, um engenheiro de automação de uma planta deve realizar a verificação das suas características desejadas consultando o fabricante. Independente do posicionamento do fabricante em relação a tais características, é prudente efetuar a validação das mesmas com a realização de um Teste de Aceitação em Fábrica ou FAT (Factory Acceptance Test). Tal fase de avaliação do sistema ou equipamentos é altamente recomendada, já que nem sempre fica claro para ambas as partes (fabricante / engenharia de automação da planta) quais são os comportamentos esperados, sobretudo no que diz respeito aos detalhes de funcionamento específicos da aplicação em questão. Os conceitos apresentados podem também servir de base para a geração de um plano de teste para o FAT sobretudo no aspecto de apontar os cenários que nem sempre estão explícitos dentre as necessidades já conhecidas da planta. 7. REFERÊNCIAS BIBLIOGRÁFICAS SALUJA, K. K. (2007). ECE 753: Fault--Tolerant Computing Lectures, Disponível em: http://homepages.cae.wisc.edu/~ece753/INFO.html SHOOMAN, M. L. (2002). Reliability of Computer Systems and Networks: Fault Tolerance, Analysis, and Design. John Wiley & Sons,Inc. Capítulos 3 e 4. LAPRIE, J.-C.; ARLAT, J.; BEOUNES, C; KANOUN, K. (1990). Definition and analysis of hardware and software fault-tolerant architectures, IEEE Computer, vol. 23, no. 7, pp. 39,51. FIELDBUS FOUNDATION (2005). FF-593: High Speed Ethernet (HSE) Redundancy Specification FS 1.34. Austin. MADREN, F. (2004). Timing networks to a fault, InTech November 2004, p. 64. ANSI/IEEE (2004). IEEE Std 802.1D, Standard for Local and metropolitan area networks. Disponível em: http://standards.ieee.org/getieee802/download/802.1D-2004.pdf, pp. 137. THE INTERNET ENGINEERING TASK FORCE (2002). STD0062: RFCs 3411 – 3418. Disponível em: http://tools.ietf.org/html/rfc3411 a http://tools.ietf.org/html/rfc3418 EVENTHELIX (2008) . System Reliability and Availability Calculation. Disponível em: http://www.eventhelix.com/RealtimeMantra/FaultHandling/system_reliability_availability.htm SMAR EQUIPAMENTOS INDUSTRIAIS (2008). Disponível em: <http://www.smar.com.br/>. FIELDBUS FOUNDATION (2008). Glossário Fieldbus/Automação. Disponível em:< http://www.fieldbus.org/index.php?option=com_glossary&Itemid=192>. CISCO SYSTEMS, INC AND ROCKWELL AUTOMATION (2007). Ethernet-to-the-Factory 1.1 Design and Implementation Guide. DADOS DO AUTOR Rodrigo Aznar Mendes Divisão de Desenvolvimento Eletrônico Smar Equipamentos Industriais (Sertãozinho – SP) Endereço: Rua Dr. Antônio Furlan Jr., 1028 Telefone: +55 16 3946-3516 – Ext. 6691 Fax: +55 16 3946-3577 e-mail: rodrigomendes@smar.com.br 1

×