SlideShare une entreprise Scribd logo
1  sur  12
Télécharger pour lire hors ligne
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. 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
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
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
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
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
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
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
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
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
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
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

Contenu connexe

Tendances

Apostila do treinamento profibus configuração
Apostila do treinamento profibus   configuraçãoApostila do treinamento profibus   configuração
Apostila do treinamento profibus configuraçãoconfidencial
 
GT-Digital Preservation - Camada de Gerenciamento
GT-Digital Preservation - Camada de GerenciamentoGT-Digital Preservation - Camada de Gerenciamento
GT-Digital Preservation - Camada de GerenciamentoRoberto Beraldo Chaiben
 
Recuperacao Falhas em Sistemas Workflow
Recuperacao Falhas em Sistemas WorkflowRecuperacao Falhas em Sistemas Workflow
Recuperacao Falhas em Sistemas WorkflowAdriano Patrick Cunha
 
07 capítulo 5
07   capítulo 507   capítulo 5
07 capítulo 5andreypaf
 
Aula 04 qs - sistemas embarcados
Aula 04   qs - sistemas embarcadosAula 04   qs - sistemas embarcados
Aula 04 qs - sistemas embarcadosJunior Gomes
 
Manutenção Centrada na Confiabilidade - Artigo Científico
Manutenção Centrada na Confiabilidade - Artigo CientíficoManutenção Centrada na Confiabilidade - Artigo Científico
Manutenção Centrada na Confiabilidade - Artigo CientíficoJosé Lucas Teixeira
 
Apostila supervisorio indusoft ind371
Apostila supervisorio indusoft ind371Apostila supervisorio indusoft ind371
Apostila supervisorio indusoft ind371Sandra Rocha
 
Redes industriais a informática aplicada no chão das fábricas
Redes industriais   a informática aplicada no chão das fábricasRedes industriais   a informática aplicada no chão das fábricas
Redes industriais a informática aplicada no chão das fábricasWilson Mathias Pereira Florentino
 

Tendances (9)

Apostila do treinamento profibus configuração
Apostila do treinamento profibus   configuraçãoApostila do treinamento profibus   configuração
Apostila do treinamento profibus configuração
 
GT-Digital Preservation - Camada de Gerenciamento
GT-Digital Preservation - Camada de GerenciamentoGT-Digital Preservation - Camada de Gerenciamento
GT-Digital Preservation - Camada de Gerenciamento
 
Recuperacao Falhas em Sistemas Workflow
Recuperacao Falhas em Sistemas WorkflowRecuperacao Falhas em Sistemas Workflow
Recuperacao Falhas em Sistemas Workflow
 
07 capítulo 5
07   capítulo 507   capítulo 5
07 capítulo 5
 
Aula 04 qs - sistemas embarcados
Aula 04   qs - sistemas embarcadosAula 04   qs - sistemas embarcados
Aula 04 qs - sistemas embarcados
 
Manutenção Centrada na Confiabilidade - Artigo Científico
Manutenção Centrada na Confiabilidade - Artigo CientíficoManutenção Centrada na Confiabilidade - Artigo Científico
Manutenção Centrada na Confiabilidade - Artigo Científico
 
Apostila supervisorio indusoft ind371
Apostila supervisorio indusoft ind371Apostila supervisorio indusoft ind371
Apostila supervisorio indusoft ind371
 
Desenvolvimento de sistemas embarcados
Desenvolvimento de sistemas embarcadosDesenvolvimento de sistemas embarcados
Desenvolvimento de sistemas embarcados
 
Redes industriais a informática aplicada no chão das fábricas
Redes industriais   a informática aplicada no chão das fábricasRedes industriais   a informática aplicada no chão das fábricas
Redes industriais a informática aplicada no chão das fábricas
 

Similaire à Disponibilidade e Diagnóstico em Controladores

Artigo Planejamento DataCenter seguindo norma TIA 942
Artigo Planejamento DataCenter seguindo norma TIA 942Artigo Planejamento DataCenter seguindo norma TIA 942
Artigo Planejamento DataCenter seguindo norma TIA 942Guilherme Domingues
 
Implementing multiloop control_strategy_using_iec61131
Implementing multiloop control_strategy_using_iec61131Implementing multiloop control_strategy_using_iec61131
Implementing multiloop control_strategy_using_iec61131Tiago Oliveira
 
Alta disponibilidade com o oracle _11gpdf
Alta disponibilidade com o oracle _11gpdfAlta disponibilidade com o oracle _11gpdf
Alta disponibilidade com o oracle _11gpdfRodrigo Raposo
 
Tcc 9119960cabea7ff604ee3bf8588d742f
Tcc 9119960cabea7ff604ee3bf8588d742fTcc 9119960cabea7ff604ee3bf8588d742f
Tcc 9119960cabea7ff604ee3bf8588d742fJoão Bispo
 
Apostila do treinamento profibus instalação
Apostila do treinamento profibus   instalaçãoApostila do treinamento profibus   instalação
Apostila do treinamento profibus instalaçãoconfidencial
 
Apostila do treinamento profibus 2 instalação
Apostila do treinamento profibus 2  instalaçãoApostila do treinamento profibus 2  instalação
Apostila do treinamento profibus 2 instalaçãoconfidencial
 
Virtualização a Nível de Sistema Operacional e sua Proposta de Segurança
Virtualização a Nível de Sistema Operacional e sua Proposta de SegurançaVirtualização a Nível de Sistema Operacional e sua Proposta de Segurança
Virtualização a Nível de Sistema Operacional e sua Proposta de SegurançaAugusto Giles
 
Manual sol term_5.1.4
Manual sol term_5.1.4Manual sol term_5.1.4
Manual sol term_5.1.4Pedro Leite
 
Automação projeto de semáforo
Automação projeto de semáforoAutomação projeto de semáforo
Automação projeto de semáforoantonio sena
 
10 Dicas para Implementacao do OracleAS
10 Dicas para Implementacao do OracleAS10 Dicas para Implementacao do OracleAS
10 Dicas para Implementacao do OracleASacsvianabr
 

Similaire à Disponibilidade e Diagnóstico em Controladores (20)

Artigo Planejamento DataCenter seguindo norma TIA 942
Artigo Planejamento DataCenter seguindo norma TIA 942Artigo Planejamento DataCenter seguindo norma TIA 942
Artigo Planejamento DataCenter seguindo norma TIA 942
 
Implementing multiloop control_strategy_using_iec61131
Implementing multiloop control_strategy_using_iec61131Implementing multiloop control_strategy_using_iec61131
Implementing multiloop control_strategy_using_iec61131
 
Alta disponibilidade com o oracle _11gpdf
Alta disponibilidade com o oracle _11gpdfAlta disponibilidade com o oracle _11gpdf
Alta disponibilidade com o oracle _11gpdf
 
Apresentação
ApresentaçãoApresentação
Apresentação
 
Automação
AutomaçãoAutomação
Automação
 
Tcc 9119960cabea7ff604ee3bf8588d742f
Tcc 9119960cabea7ff604ee3bf8588d742fTcc 9119960cabea7ff604ee3bf8588d742f
Tcc 9119960cabea7ff604ee3bf8588d742f
 
Apostila do treinamento profibus instalação
Apostila do treinamento profibus   instalaçãoApostila do treinamento profibus   instalação
Apostila do treinamento profibus instalação
 
Apostila do treinamento profibus 2 instalação
Apostila do treinamento profibus 2  instalaçãoApostila do treinamento profibus 2  instalação
Apostila do treinamento profibus 2 instalação
 
Manual SLC500.pdf
Manual SLC500.pdfManual SLC500.pdf
Manual SLC500.pdf
 
Redes
RedesRedes
Redes
 
Virtualização
VirtualizaçãoVirtualização
Virtualização
 
Virtualização a Nível de Sistema Operacional e sua Proposta de Segurança
Virtualização a Nível de Sistema Operacional e sua Proposta de SegurançaVirtualização a Nível de Sistema Operacional e sua Proposta de Segurança
Virtualização a Nível de Sistema Operacional e sua Proposta de Segurança
 
Manual sol term_5.1.4
Manual sol term_5.1.4Manual sol term_5.1.4
Manual sol term_5.1.4
 
RCM- Manutenção Centrada na Confiabilidade
RCM- Manutenção Centrada na ConfiabilidadeRCM- Manutenção Centrada na Confiabilidade
RCM- Manutenção Centrada na Confiabilidade
 
Aula04 3
Aula04 3Aula04 3
Aula04 3
 
Automação projeto de semáforo
Automação projeto de semáforoAutomação projeto de semáforo
Automação projeto de semáforo
 
Aula 6 semana
Aula 6 semanaAula 6 semana
Aula 6 semana
 
10 Dicas para Implementacao do OracleAS
10 Dicas para Implementacao do OracleAS10 Dicas para Implementacao do OracleAS
10 Dicas para Implementacao do OracleAS
 
APOSTILA MANUTENÇÃO ELÉTRICA.pdf
APOSTILA MANUTENÇÃO ELÉTRICA.pdfAPOSTILA MANUTENÇÃO ELÉTRICA.pdf
APOSTILA MANUTENÇÃO ELÉTRICA.pdf
 
Ctc m3 v5_t
Ctc m3 v5_tCtc m3 v5_t
Ctc m3 v5_t
 

Disponibilidade e Diagnóstico em Controladores

  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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