FTA: Análise de Árvore de Falhas

FTA ou Análise de Árvore de Falhas: evento de topo, portas AND/OR, minimal cut sets, probabilidade, causa comum, redundância e aplicações em engenharia.

Confira!

FTA — Fault Tree Analysis, ou Análise de Árvore de Falhas — é uma técnica dedutiva utilizada para estudar como falhas, condições e combinações de eventos podem produzir um evento indesejado previamente definido. A análise começa pelo efeito que se deseja compreender, chamado evento de topo, e avança de cima para baixo decompondo suas causas por meio de relações lógicas até chegar a eventos suficientemente elementares para análise e tratamento.

A técnica é especialmente útil quando a perda de uma função não depende de uma única falha, mas da interação entre redundâncias, proteções, utilidades, interfaces, software, erro humano e condições comuns. Em vez de apenas listar causas possíveis, a árvore mostra quais eventos isolados são suficientes, quais precisam ocorrer em conjunto e quais dependências podem invalidar uma redundância aparentemente robusta.

Uma FTA pode ser qualitativa ou quantitativa. Na análise qualitativa, o objetivo é identificar caminhos de falha, pontos únicos, dependências e conjuntos mínimos capazes de levar ao evento de topo. Na abordagem quantitativa, probabilidades, indisponibilidades ou frequências podem ser propagadas pela lógica da árvore, desde que os dados, as unidades e as premissas de independência sejam tecnicamente adequados.

FTA não é sinônimo de FMEA nem de análise de causa raiz. FMEA parte dos modos de falha de componentes e analisa seus efeitos; FTA parte de um evento indesejado e busca as combinações capazes de produzi-lo. RCA normalmente investiga uma ocorrência real para evitar sua repetição. A escolha da técnica depende da pergunta de engenharia que precisa ser respondida.

Evento de topo e fronteira: onde a FTA realmente começa

A qualidade da árvore depende da definição do problema. Um evento de topo como “falha do sistema” é amplo demais para orientar uma decomposição consistente. Uma formulação como “perda total de alimentação da carga crítica por período superior ao tempo de transferência admissível durante operação normal” delimita função, condição e critério de falha.

Antes de construir a lógica, também é necessário estabelecer a fronteira do sistema. Fontes externas, utilidades, pessoas, software, ambiente, proteção, telecomunicações e sistemas auxiliares podem estar dentro ou fora do escopo. Um elemento colocado fora da fronteira pode aparecer como evento básico; o mesmo elemento, quando faz parte do sistema estudado, precisa ser desenvolvido.

Uma definição adequada registra pelo menos:

função ou condição perdida;
sistema e interfaces considerados;
estado operacional analisado;
duração ou limite relevante, quando aplicável;
hipóteses de redundância e reparo;
elementos explicitamente excluídos.

Essa formalização evita árvores que crescem sem critério e permite que outra equipe compreenda exatamente qual condição foi modelada.

Eventos e portas lógicas da Árvore de Falhas

A árvore utiliza eventos e portas para representar relações causais. O evento básico é aquele que não será decomposto adicionalmente dentro do objetivo da análise; isso não significa que seja fisicamente indivisível, apenas que atingiu o nível de detalhe considerado suficiente.

Elemento	Interpretação prática
Evento de topo	condição indesejada que inicia a análise
Evento intermediário	condição resultante da combinação de eventos inferiores
Evento básico	evento tratado como elementar no escopo da árvore
Evento não desenvolvido	evento cuja decomposição não foi realizada, com justificativa
Porta OR	qualquer uma das entradas pode produzir a saída
Porta AND	todas as entradas precisam ocorrer para produzir a saída

Considere um sistema de ventilação cuja perda possa ocorrer por falha do ventilador, perda de sua alimentação ou comando bloqueado. Se qualquer uma dessas condições for suficiente, a relação é representada por uma porta OR. Em outra situação, uma carga alimentada por duas vias independentes pode ser perdida somente se a via A e a via B estiverem indisponíveis; a relação é representada por AND.

A lógica deve representar a condição física real, e não a aparência do diagrama. Se as duas vias compartilham um mesmo barramento, controlador ou ambiente, a suposição de independência precisa ser revista antes de tratá-las simplesmente como eventos AND independentes.

Como construir uma FTA passo a passo

Uma sequência tecnicamente consistente é:

Definir o objetivo da análise. Determinar se a árvore será utilizada para projeto, segurança, disponibilidade, diagnóstico, comparação de alternativas ou quantificação de risco.
Definir o evento de topo. Especificar função perdida, condição operacional, limite e duração quando relevantes.
Estabelecer a fronteira. Registrar sistemas, interfaces, fontes externas e condições incluídas.
Identificar causas imediatas. Perguntar quais condições são necessárias ou suficientes para produzir o evento de topo.
Aplicar as portas lógicas. Conectar eventos por relações coerentes com o comportamento físico e funcional.
Decompor eventos intermediários. Continuar até alcançar eventos básicos adequados ao propósito do estudo.
Analisar dependências e causas comuns. Verificar elementos compartilhados entre caminhos aparentemente redundantes.
Gerar e revisar cut sets. Identificar combinações mínimas que produzem o evento de topo.
Quantificar, quando necessário. Aplicar dados de probabilidade, indisponibilidade ou frequência com premissas explícitas.
Transformar resultados em decisão. Avaliar redesign, monitoramento, manutenção, barreiras, testes ou procedimentos.

A decomposição deve parar quando o nível atingido permite decisão. Desenvolver componentes irrelevantes até níveis microscópicos não melhora necessariamente a análise; parar cedo demais, por outro lado, pode esconder causas comuns ou ações de engenharia possíveis.

Minimal cut sets e análise qualitativa

Um cut set é um conjunto de eventos básicos cuja ocorrência conjunta é suficiente para produzir o evento de topo. Um minimal cut set é mínimo no sentido lógico: se qualquer evento for retirado, aquela combinação deixa de ser suficiente.

Imagine uma árvore em que o evento de topo ocorre se A e B falharem simultaneamente ou se C falhar sozinho. Os conjuntos mínimos são:

{A, B};
{C}.

O segundo é um conjunto de primeira ordem: um único evento é suficiente para produzir o topo. Em sistemas que pretendem ser tolerantes a uma falha, esse resultado merece análise imediata porque pode representar um Single Point of Failure — SPOF.

A ordem do cut set não é, sozinha, medida de risco. Um conjunto de primeira ordem com probabilidade extremamente baixa pode contribuir menos para o risco total do que uma combinação de segunda ordem composta por eventos frequentes. A análise qualitativa identifica a estrutura lógica; a priorização precisa considerar também probabilidade, consequência, detectabilidade e contexto operacional.

Esse tipo de raciocínio complementa a Análise de Criticidade de Ativos, que ajuda a decidir onde uma análise detalhada de falhas gera maior valor.

Como calcular probabilidades em portas AND e OR

A quantificação exige atenção à variável utilizada. Probabilidade de falha durante uma missão, indisponibilidade em determinado instante e frequência de ocorrência são grandezas relacionadas, mas não intercambiáveis automaticamente.

Para dois eventos independentes A e B ligados por uma porta AND:

P(A ∩ B) = P(A) × P(B)

Se cada caminho possui probabilidade de indisponibilidade de 0,01 na condição analisada e a independência é tecnicamente válida:

P(AND) = 0,01 × 0,01 = 0,0001, ou 0,01%.

Para uma porta OR com dois eventos independentes:

P(A ∪ B) = P(A) + P(B) − P(A)P(B)

Com vários eventos independentes, a probabilidade de pelo menos um ocorrer pode ser escrita como:

P(OR) = 1 − ∏(1 − Pi)

Quando todos os eventos são raros, a soma das probabilidades pode ser utilizada como aproximação em determinadas análises, mas essa simplificação precisa ser reconhecida como aproximação.

O problema mais relevante, porém, geralmente não é a álgebra: é a validade das premissas. Multiplicar probabilidades de duas vias que compartilham a mesma alimentação auxiliar ou o mesmo software pode produzir um resultado aparentemente excelente e tecnicamente enganoso.

Falhas de causa comum e dependências entre redundâncias

Redundância de equipamentos não significa independência funcional. Duas vias podem compartilhar elementos capazes de derrubá-las simultaneamente:

barramento ou alimentação auxiliar;
sala ou condição ambiental;
rota física de cabos;
lógica de controle ou firmware;
sistema de refrigeração;
aterramento;
equipe e procedimento de manutenção;
configuração comum;
utilidade externa.

Considere duas fontes A e B que alimentam uma carga crítica, mas convergem em um único painel de saída. Uma árvore simplificada pode representar a perda da carga como:

falha do painel comum OR (falha da via A AND falha da via B).

A arquitetura possui redundância nas fontes, mas o painel comum cria um caminho de primeira ordem para o evento de topo. A FTA torna explícito aquilo que um diagrama com “duas fontes” pode ocultar.

O mesmo raciocínio se aplica a redes com dois switches conectados por uma única rota de fibra, bombas redundantes com sucção comum ou controladores duplicados executando a mesma configuração incorreta. A engenharia precisa avaliar independência de função, não apenas quantidade de equipamentos.

Esse princípio é central em Reliability by Design, especialmente em arquiteturas que dependem de tolerância a falhas.

Condição normal, manutenção e estados degradados

Uma árvore representa um estado definido. Um sistema pode atender ao critério de redundância em operação normal e perder essa característica durante manutenção, teste ou contingência.

Por isso, sistemas críticos podem exigir árvores ou cenários específicos para condições como:

Estado	Questão de engenharia
Operação normal	quais combinações levam à perda da função com todos os caminhos disponíveis?
Uma via em manutenção	quais eventos adicionais passam a ser suficientes para o topo?
Operação degradada	quais barreiras permanecem efetivas?
Partida ou transferência	existem falhas específicas de sequência, comando ou sincronismo?
Modo manual	a intervenção humana introduz novos caminhos de falha?

Essa abordagem evita avaliar disponibilidade apenas na configuração nominal. Em instalações de missão crítica, a manutenção concorrente e as transições de estado podem ser tão importantes quanto a arquitetura estática.

FTA, FMEA, RCA e RAM: qual técnica responde a qual pergunta

As técnicas são complementares e devem ser escolhidas pela pergunta que se pretende responder.

Técnica	Direção / foco	Pergunta típica
FTA	dedutiva, top-down	quais combinações podem produzir este evento de topo?
FMEA	indutiva, bottom-up	o que acontece quando este modo de falha ocorre?
RCA	investigativa	por que esta ocorrência aconteceu e como evitar recorrência?
RAM	desempenho do sistema	qual confiabilidade, disponibilidade e mantenabilidade a arquitetura entrega?

Uma FMEA pode fornecer modos de falha relevantes para a árvore. Uma Análise de Causa Raiz pode utilizar lógica semelhante para testar hipóteses após uma ocorrência, mas não se torna automaticamente uma FTA formal. Uma Análise RAM pode utilizar modelos de falha e reparo para avaliar desempenho global da arquitetura.

Separar essas responsabilidades evita produzir várias análises diferentes com o mesmo conteúdo e nomes distintos.

FTA em projeto, Design Review e manutenção

FTA pode ser aplicada antes de uma falha ocorrer. Em projeto e Design Review, a técnica ajuda a verificar pontos únicos, dependências comuns, cobertura de proteção e comportamento em estados degradados. Uma alteração de arquitetura pode então ser comparada pela redução ou eliminação de caminhos críticos.

Durante operação, a árvore também pode apoiar definição de testes e estratégias de manutenção. Se uma função de proteção permanece oculta até ser demandada, a FTA pode evidenciar a importância do teste funcional. Se determinados eventos básicos dominam os cut sets, monitoramento de condição, sobressalentes ou revisão de frequência podem ser mais efetivos do que aumentar indiscriminadamente a manutenção preventiva.

Quando a análise indica necessidade de revisão estruturada da estratégia, a interface natural é com Engenharia de Confiabilidade e Disponibilidade, Gerenciamento de Riscos de Engenharia e Design Review, conforme a fase do ciclo de vida.

FTA não precisa terminar no diagrama. Quando integrada à governança técnica, ela pode sustentar decisões de projeto, revisão independente, priorização de riscos, requisitos de redundância e critérios de aceite.

Conheça o Owner’s Engineering da A3A →

FTA como instrumento de governança, assurance e decisão de engenharia

A FTA ganha maior valor quando deixa de ser tratada como um diagrama isolado e passa a integrar o sistema de decisão de engenharia. A própria terminologia brasileira de confiabilidade e mantenabilidade associa a gestão da confiabilidade a atividades planejadas, controle, auditoria, supervisão e revisão de projeto. Nesse contexto, a árvore de falhas pode funcionar como evidência técnica para justificar requisitos, verificar arquiteturas, priorizar riscos e sustentar decisões em diferentes fases do ciclo de vida.

Em organizações com governança técnica estruturada, o modelo pode ser incorporado a processos de Engenharia de Confiabilidade e Disponibilidade, Gerenciamento de Riscos de Engenharia, Design Review e Owner’s Engineering. Cada uma dessas disciplinas utiliza a análise com uma finalidade diferente, mas todas dependem de requisitos, critérios de decisão e rastreabilidade.

Fase	Uso da FTA	Decisão suportada
Concepção / FEED	comparar arquiteturas, redundâncias e pontos únicos	seleção de alternativa e requisitos de confiabilidade
Projeto	verificar interfaces, proteções e causas comuns	redesign, segregação, instrumentação e critérios de teste
Contratação	traduzir riscos em requisitos verificáveis	especificações, garantias, FAT/SAT e responsabilidades
Implantação	validar se barreiras e redundâncias foram materializadas	aceite, punch list, testes integrados e correções
Operação	reavaliar cenários com dados de campo e estados degradados	manutenção, monitoramento, sobressalentes e contingência
Mudança / retrofit	comparar risco antes e depois da modificação	aprovação de mudança e risco residual

Essa integração transforma a FTA em parte do Project Assurance: a análise não serve apenas para “mostrar risco”, mas para verificar se a solução proposta atende aos requisitos e se as decisões possuem base técnica suficiente. Em projetos críticos, a Auditoria Técnica de Engenharia pode utilizar árvores existentes, premissas, registros de teste e evidências de campo para avaliar coerência entre projeto, condição instalada e desempenho.

Uma árvore de falhas usada para decisão precisa ser controlada como informação de engenharia. Premissas, versões, responsáveis, fontes de dados e critérios de revisão devem permanecer rastreáveis ao longo das mudanças do sistema.

Conheça Gestão de Requisitos, Evidências e Critérios de Aceite →

Governança do modelo: responsáveis, premissas, versões e mudanças

Uma FTA utilizada para decisão precisa ser governada como informação de engenharia. Deve existir um responsável pelo modelo, uma definição clara do evento de topo, controle das premissas, identificação das fontes de dados, versionamento e critérios de revisão. Sem isso, duas equipes podem analisar o mesmo sistema com fronteiras e hipóteses diferentes e produzir resultados que parecem comparáveis, mas não são.

Essa necessidade conecta a análise à Governança Documental, à Gestão de Requisitos, Evidências e Critérios de Aceite e à Gestão de Processos, Workflows e Aprovações Técnicas. O modelo pode ter estados de elaboração, revisão independente, aprovação e obsolescência, da mesma forma que outros documentos de engenharia que suportam decisões críticas.

Mudanças também precisam disparar reavaliação. Alterar firmware, lógica de controle, alimentação auxiliar, topologia de rede, rota física, configuração de proteção, estratégia de manutenção ou fornecedor pode modificar dependências existentes na árvore. A Gestão de Pendências, RFIs e Não Conformidades ajuda a manter visíveis os desvios identificados, enquanto processos formais de aprovação evitam que uma modificação invalide premissas de confiabilidade sem que ninguém perceba.

Na transição entre implantação e operação, a árvore deve ser reconciliada com a condição realmente construída. Comissionamento de Engenharia, As-Built, Recebimento Técnico e Recomissionamento são pontos naturais para confirmar se redundâncias, proteções e interfaces representadas no modelo existem e funcionam como previsto.

FTA integrada à gestão de ativos e à engenharia de manutenção

Na gestão de ativos, o objetivo não é eliminar qualquer possibilidade de falha, mas decidir onde aplicar recursos para gerar valor considerando desempenho, risco, custo e horizonte de vida. A FTA contribui para essa decisão ao mostrar quais eventos e combinações dominam determinado cenário. Esse resultado pode alimentar Engenharia de Manutenção, Gestão de Ativos de Engenharia e planos de confiabilidade.

Se um evento básico de primeira ordem está associado a um componente sem redundância, a resposta pode ser redesign. Se o risco decorre de falha latente em uma proteção, a resposta pode ser teste periódico. Se a contribuição principal vem de causa comum ambiental, a solução pode ser segregação ou monitoramento. Se a indisponibilidade depende de longos atrasos logísticos, a decisão pode envolver sobressalentes, contrato de suporte ou estratégia de reparo. A mesma árvore, portanto, pode orientar projeto, manutenção, suprimentos e operação.

Essa leitura é especialmente importante para ativos e sistemas críticos, em que uma análise puramente por equipamento pode perder dependências funcionais. Conteúdos sobre Plano de Gestão de Ativos, Engenharia de Manutenção e Análise RAM complementam a FTA ao conectar o cenário de falha a objetivos, desempenho e ciclo de vida.

Aplicações transversais em infraestrutura crítica

A técnica é transversal porque o raciocínio funcional independe da disciplina. Em uma subestação, o evento de topo pode ser perda de teleassistência, indisponibilidade de proteção ou perda de alimentação auxiliar. Em um Data Center, pode ser perda de energia para uma carga crítica ou indisponibilidade térmica. Em segurança eletrônica, pode ser perda de cobertura de uma área ou incapacidade de gravação. Em telecomunicações, pode ser perda de conectividade entre pontos críticos.

Essa transversalidade aparece em soluções como Teleassistência e Monitoramento Operativo em Subestações, Engenharia Integrada para Data Centers, Instalações Elétricas de Média Tensão e sistemas integrados de segurança, nos quais disponibilidade depende de múltiplas interfaces técnicas.

Nos projetos publicados da A3A, esse tipo de complexidade pode ser observado em diferentes contextos. O monitoramento operativo para suporte à teleassistência em subestação de transmissão combina operação remota, redes e sistemas de monitoramento; os projetos turnkey de monitoramento em Londrina, Umuarama e Guaíra mostram arquiteturas distribuídas em ambiente de transmissão.

Em outra tipologia, o FEED de sistema de vigilância eletrônica em usina hidrelétrica e o FEED de telecomunicações no mesmo empreendimento evidenciam a necessidade de analisar interfaces desde as etapas de definição. Já a implantação turnkey de sistema integrado em complexo governamental demonstra a aplicação em ambiente com múltiplos subsistemas, infraestrutura, redes e operação.

Quando a falha potencial afeta continuidade, segurança ou desempenho, a análise precisa sair do campo conceitual e virar decisão de engenharia. FTA pode ser combinada com RAM, FMEA/FMECA, criticidade, dados de campo e revisão de arquitetura para formar um estudo de confiabilidade tecnicamente defensável.

Conheça Engenharia de Confiabilidade e Disponibilidade →

Como uma análise de confiabilidade pode ser contratada

Uma contratação de FTA não precisa se limitar à entrega de uma árvore. Em uma abordagem de engenharia consultiva, o trabalho pode incluir levantamento de requisitos, definição de fronteira, workshops técnicos, modelagem, análise de cut sets, quantificação quando aplicável, revisão independente, recomendações, matriz de ações e integração com registros de riscos e mudanças.

Dependendo do estágio do ativo, esse escopo pode ser desenvolvido como Consultoria Técnica de Engenharia, dentro de um Design Review, como apoio à Engenharia do Proprietário ou em regime de Serviços Continuados de Engenharia Consultiva. O diferencial está em transformar a análise em decisão rastreável e acompanhar se as ações recomendadas realmente alteraram o risco.

Dados, premissas e validação da árvore

Uma FTA quantitativa precisa registrar origem e aplicabilidade dos dados. Histórico próprio, dados de fabricante, bancos de confiabilidade, ensaios e análises estatísticas podem ser utilizados, mas nenhuma fonte elimina a necessidade de verificar regime operacional, população e unidade temporal.

Premissas como independência, tempo de missão, estado inicial, política de reparo, cobertura de proteção e disponibilidade de recursos precisam permanecer visíveis. Sem elas, o número calculado não é reproduzível.

A revisão técnica deve verificar se o evento de topo continua corretamente definido, se a fronteira é coerente, se eventos repetidos foram tratados como o mesmo evento, se causas comuns estão representadas e se os cut sets fazem sentido físico. Mudanças de projeto, configuração ou operação podem invalidar uma árvore antiga mesmo que sua lógica matemática permaneça correta.

Entre os erros mais recorrentes estão assumir independência sem justificativa, misturar taxa de falha com probabilidade, ignorar condições de manutenção, decompor eventos sem relevância e aceitar a saída numérica do software sem revisão de engenharia.

A FTA está concluída quando sua lógica e suas premissas permitem responder à pergunta original e orientar uma decisão. O objetivo não é produzir a maior árvore possível, mas revelar de forma rastreável como o evento de topo pode ocorrer, quais caminhos dominam o risco e quais mudanças realmente alteram esse resultado.

Referências técnicas

[1] IEC. IEC 61025:2006 — Fault tree analysis (FTA).

[2] IEC. IEC 31010:2019 — Risk management — Risk assessment techniques.

[3] ABNT. ABNT NBR 5462:1994 — Confiabilidade e mantenabilidade — Terminologia.

[4] ISO. ISO 55000:2024 — Asset management — Vocabulary, overview and principles.

[5] ISO. ISO 55001:2024 — Asset management — Asset management system — Requirements.

[6] ISO. ISO 21505:2017 — Project, programme and portfolio management — Guidance on governance.

Perguntas frequentes

O que é FTA?

FTA, ou Fault Tree Analysis, é uma técnica dedutiva que parte de um evento de topo indesejado e decompõe logicamente as combinações de eventos capazes de produzi-lo.

Qual a diferença entre FTA e FMEA?

FTA é top-down: parte de um evento indesejado e procura suas combinações causais. FMEA é bottom-up: parte dos modos de falha e analisa seus efeitos.

O que significa uma porta AND na FTA?

A porta AND indica que todas as entradas precisam ocorrer para produzir a saída. Para eventos independentes, a probabilidade conjunta pode ser calculada pelo produto das probabilidades.

O que significa uma porta OR na FTA?

A porta OR indica que qualquer uma das entradas é suficiente para produzir a saída. A probabilidade da união precisa considerar a sobreposição entre eventos.

O que é minimal cut set?

É um conjunto mínimo de eventos básicos cuja ocorrência conjunta é suficiente para produzir o evento de topo. Se qualquer evento for retirado, aquela combinação deixa de ser suficiente.

FTA precisa ser quantitativa?

Não. A análise qualitativa já pode revelar pontos únicos de falha, dependências, causas comuns e caminhos críticos. A quantificação deve ser usada quando dados e premissas são adequados.

Materiais técnicos complementares

Serviços de Engenharia relacionados

Conteúdos técnicos correlatos

Guias e referenciais