FTA (Fault Tree Analysis) – Parte I

Luis Cyrino
11 jun 2017
0
25652

FTA (Fault Tree Analysis) – Parte I

Conceitos e Aplicações

FTA é um método que foi desenvolvido por volta de 1960, por W.A. Watson, da empresa Bell Laboratories e aperfeiçoada pela Boeing Corporation. Consiste em um processo lógico e dedutivo que, partindo de um evento indesejado e pré-definido (EVENTO TOPO), busca-se as possíveis causas de tal evento.

Essa metodologia tem por objetivo melhorar a confiabilidade em geral de produtos e de processos usando a técnica da análise sistemática de possíveis falhas e suas consequências, buscando assim um processo decisório para adoção de medidas adequadas para fazer frente a esses problemas e saná-los.

Um modelo indutivo define cenários para um Evento Inicial

Inicialmente, é definido um evento que pode ter consequências indesejáveis, logo identificam-se eventos subsequentes que definem possíveis progressões do evento iniciador. Possíveis realizações dos eventos subsequentes são definidas e vinculadas a cenários modelo e a consequência de cada cenário é descrita.

Um Modelo Dedutivo resolve as causas para um evento

Primeiro é definido um evento para o qual as causas devem ser resolvidas, sendo o evento resolvido em seus imediatos e necessários eventos causais suficientes. O evento está relacionado com os eventos causais usando a lógica apropriada e esta resolução gradual de eventos em eventos causais imediatos ocorre até que causas básicas (causas primárias) sejam identificadas.

FTA, um Processo Sistemático e Dedutivo Estilizado

Parte da definição de um evento indesejado onde o mesmo é resolvido em suas causas imediatas. Esta resolução de eventos continua até que sejam identificadas causas básicas e com isso um diagrama lógico chamado uma árvore de falha é construído mostrando as relações desses eventos lógicos.

Benefícios da construção de uma árvore de falhas

A árvore de falhas mostra explicitamente todas as relações diferentes que são necessárias para resultar no evento superior. Ao construir a árvore de falhas, obtém-se uma compreensão completa da lógica e das causas básicas que levam ao evento de topo. A árvore de falhas é um registro tangível da análise sistemática da lógica e causas básicas que levam ao evento de topo e fornece uma estrutura para avaliação qualitativa e quantitativa completa do evento de topo.

Elementos de Análise de Árvore de Falhas (FTA)

A FTA é uma abordagem de análise dedutiva para resolver um evento indesejado em suas causas, é uma análise de retrocesso, olhando para trás as causas de um determinado evento. A lógica passo a passo específica é usada no processo, símbolos lógicos específicos são usados para ilustrar as relações de eventos e um diagrama lógico é construído mostrando as relações de eventos.

A árvore de falhas é o modelo lógico da relação entre o evento indesejado e eventos mais básicos, onde o evento superior da árvore de falhas é o evento indesejado. Os eventos médios são eventos intermediários, a parte inferior da árvore de falhas são os eventos básicos causais ou eventos primários. Os relacionamentos lógicos dos eventos são mostrados por símbolos ou portas lógicas.

Objetivos da realização da FTA

  1. Identificar exaustivamente as causas de uma falha.
  2. Identificar as deficiências de um sistema.
  3. Avaliar um projeto proposto para sua confiabilidade e segurança.
  4. Identificar os efeitos de erros humanos.
  5. Priorizar os que contribuem para a falha.
  6. Identificar atualizações efetivas de um sistema.
  7. Para quantificar a probabilidade de falha e seus contribuintes.
  8. Otimizar testes e manutenções.

O Processo do Pensamento no FTA

O FTA é retroativo, seu resultado final é o ponto de partida da análise, é então traçado de volta um passo de cada vez para suas causas imediatas. As relações das causas, ou eventos, são mostradas com símbolos lógicos e esse processo de rastreamento para trás continua até que as causas básicas sejam identificadas. A FTA sistematiza e codifica o processo.

Comparação de FTA com outras abordagens:

  1. FTA não é uma análise de causa e efeito (Ishikawa) que é uma descrição mais informal das causas do evento (dedutivo informal).
  2. O FTA não é um FMEA que avalia diferentes efeitos de causas básicas únicas (indutivas).
  3. FTA não é a Análise de Árvore de Eventos que avalia as consequências de determinados eventos iniciadores (indutivos).
  4. FTA é uma abordagem formal para resolver as causas básicas de um determinado evento indesejável (dedutivo formal).

Modos de Falha

Um modo de falha é o estado de falha do sistema ou componente, exemplos de modos de falha não são iniciados, não abrem, falham ao desligar. Em contraste, mecanismos de falha são os processos pelos quais ocorrem as falhas, exemplos de mecanismos de falha são corrosão, sobre pressão e fadiga. Um mecanismo de falha só é incluído na definição do modo de falha quando são modelados em mecanismos detalhados.

Estrutura básica da árvore de falhas

 

  As quatro etapas necessárias para iniciar uma árvore de falhas

  1. Definir o evento indesejado a ser analisado (o foco do FTA).
  2. Definir o limite do sistema (o escopo do FTA).
  3. Definir os eventos causais básicos a serem considerados.
  4. Definir o estado inicial do sistema.

Ilustração dos Passos de um FTA

 

  Eventos básicos de uma árvore de falhas

 

  Portas básicas de uma árvore de falhas

 

  O Evento Superior da Árvore de Falhas

O evento de topo deve descrever o QUE é esse evento e QUANDO acontece, é muitas vezes uma falha do sistema, mas pode ser qualquer outro evento. O evento de topo é o evento específico a ser resolvido em suas causas básicas, portanto definir o evento superior erradamente resultará em avaliações e conclusões incorretas.

A porta “OU”

  1. A porta OU representa a união lógica das entradas: a saída ocorre se alguma das entradas ocorrer.
  2. A porta OU é usada quando um evento é resolvido em causas ou cenários mais específicos.
  3. A porta OU é usado quando uma falha de componente é resolvida em uma falha inerente ou uma falha de comando.
  4. A porta OU é usada quando um evento é descrito em termos de eventos equivalentes e mais específicos.

Porta “OU” para resolver falha de componente em falhas específicas

 

  A porta “E”

  1. A porta “E” representa a intersecção lógica das entradas: a saída ocorre se todas as entradas ocorrerem.
  2. A porta “E” é usada quando um evento é resolvido em combinações de eventos que precisam ocorrer.
  3. A porta “E” é usada quando um sistema redundante é resolvido em vários subsistemas que precisam falhar.
  4. A porta “E” é usada quando uma falha do sistema é resolvida em condições e eventos necessários para ocorrer.

Porta “E” para uma fonte de alimentação redundante

  Resumo das portas “OU” e “E”

 

  Ligando as portas “OU” e “E”

 

  Terminando eventos em uma árvore de falha

Os eventos de terminação de uma árvore de falha identificam onde a FTA pára, dois eventos terminais fundamentais são o evento básico e o evento não desenvolvido. O evento básico representa o evento de nível mais baixo (causa) resolvido na árvore de falhas se o evento subdesenvolvido representar um evento que não é desenvolvido para causas.

Tipos expandidos de eventos finais

 

  Desenvolvendo a árvore de falhas

  1. Definir o evento superior como um retângulo;
  2. Determinar os eventos imediatos necessários e suficientes que resultem no evento de topo;
  3. Desenhe a porta apropriada para descrever a lógica dos eventos intermediários resultando no evento superior;
  4. Tratar cada evento intermediário como um evento de nível superior intermediário;
  5. Determinar as causas imediatas, necessárias e suficientes para cada evento intermediário;
  6. Determinar a porta apropriada e continuar o processo.

Necessário no desenvolvimento da árvore de falhas

  1. O sistema que está sendo analisado para o evento indesejado precisa ser estudado e compreendido antes que a árvore de falha seja construída;
  2. Se um sistema elétrico ou hidráulico está sendo analisado, a árvore de falhas é construída traçando as causas em geral no circuito para as causas básicas;
  3. Para uma rede ou fluxo generalizado, a árvore de falhas é similarmente construída por um rastreamento em geral das causas.

Lembre-se dos quatro atributos-chave de uma árvore de falhas

  1. Evento principal- Que evento específico está sendo analisado?
  2. O que está dentro e fora da análise?
  3. Resolução – Quais são as principais causas a serem resolvidas?
  4. Estado Inicial – O que é assumido para as condições e estados iniciais?

Definindo o limite e a resolução da Árvore de Falhas

O limite define o que está dentro da análise e o que está fora da análise, a resolução define as causas básicas a serem resolvidas. O limite define as interfaces a serem incluídas ou excluídas e a resolução define que tipos de eventos são modelados.

O estado inicial para a árvore de falhas

O estado inicial da FTA define os estados iniciais dos componentes, condições iniciais e entradas iniciais assumidas, os estados iniciais dos componentes envolvem quais componentes são assumidos como inicialmente operacionais.

O estado inicial também pode envolver a descrição do histórico passado do componente, as condições iniciais incluem ambientes assumidos e condições operacionais. Também as entradas iniciais incluem comandos iniciais assumidos, falhas assumidas existentes e eventos assumidos que ocorreram.

 A árvore de falhas distingue uma falha de componente da falha do sistema

Importante, para cada evento, pergunte se a falha é um estado de falha de componente ou um estado de falha do sistema, a resposta determina o tipo de porta a ser construída.

Se a resposta à pergunta: Esta falha é de componente? “sim”, classificar o evento como um estado de falha de componente. Se a resposta for “não”, classificar o evento como um “estado de falha do sistema”.

Portas para falhas de componente versus falhas do sistema

Para um estado de falha de componente use uma porta “OU” se a falha não for uma falha (evento básico) e para um estado de falha do sistema, a porta depende da descrição do evento.

Se o evento de falha for classificado como “estado do componente”, adicione uma porta “OU” abaixo do evento e procure os modos de falha de comando primário, secundário e de comando.

Se o evento de falha for classificado como “estado de sistema”, procure a causa ou causas imediatas mínimas necessárias e suficientes.

Um evento de falha “estado de sistema” pode requerer uma porta “E”, uma porta “OU”, uma porta “INIBIR” ou possivelmente nenhuma porta. Como regra geral, quando a energia se origina de um ponto fora do componente, o evento pode ser classificado como “estado do sistema”.

Falha primária versus falha secundária

Uma falha pode ser melhor resolvida em uma falha primária ou numa falha secundária, sendo que uma falha primária é uma falha em ambientes de projeto e uma falha secundária é uma falha fora dos ambientes de projeto.

Geralmente falhas secundárias não são incluídas a menos que condições anormais sejam modeladas, se forem incluídas falhas secundárias, a falha secundária é resolvida para a condição anormal existente e a falha ocorre.

Guia de Modelagem de Falhas Secundárias

  1. Incluir uma falha secundária quando um ambiente anormal é de foco específico;
  2. Incluir uma falha secundária quando um ambiente anormal pode ter uma probabilidade não negligenciável de existir;
  3. Caso contrário, como regra geral, não inclua falhas secundárias na árvore de falhas, uma vez que elas podem aumentar a complexidade da árvore de falhas.

Conclusão

Na realidade não se trata de uma conclusão, mas de uma informação que teremos a segunda parte dessa matéria por ser muito extensa. Na próxima publicação falaremos mais da FTA comparando com outras ferramentas, os erros humanos envolvidos, os tipos de falhas de causas comuns. E muitas outras características dessa ferramenta que considero muito completa para a resolução de problemas. Até a próxima!!!

Referência bibliográfica

“Manual de Árvore de Falhas com Aplicações Aeroespaciais”, Versão 1.1, Publicação da NASA, agosto de 2002.

Comentários

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *