Modo de falha e análise de efeitos - Failure mode and effects analysis

Análise de efeitos e modos de falha ( FMEA ; muitas vezes escrito com "modos de falha" no plural) é o processo de revisão de tantos componentes, montagens e subsistemas quanto possível para identificar modos de falha potenciais em um sistema e suas causas e efeitos. Para cada componente, os modos de falha e seus efeitos resultantes no resto do sistema são registrados em uma planilha FMEA específica. Existem inúmeras variações dessas planilhas. Um FMEA pode ser uma análise qualitativa, mas pode ser colocado em uma base quantitativa quando os modelos matemáticos de taxa de falha são combinados com um banco de dados de razão de modo de falha estatística. Foi uma das primeiras técnicas altamente estruturadas e sistemáticas de análise de falhas . Foi desenvolvido por engenheiros de confiabilidade no final dos anos 1950 para estudar problemas que podem surgir de mau funcionamento de sistemas militares. Um FMEA geralmente é a primeira etapa de um estudo de confiabilidade do sistema.

Existem alguns tipos diferentes de análises FMEA, tais como:

• Funcional
• Projeto
• Processo

Às vezes, FMEA é estendido para FMECA (modo de falha, efeitos e análise de criticidade) para indicar que a análise de criticidade também é realizada.

FMEA é um ponto único de análise de falha de raciocínio indutivo (lógica direta) e é uma tarefa central em engenharia de confiabilidade , engenharia de segurança e engenharia de qualidade .

Uma atividade FMEA bem-sucedida ajuda a identificar modos de falha em potencial com base na experiência com produtos e processos semelhantes - ou com base na física comum da lógica de falha. É amplamente utilizado nas indústrias de desenvolvimento e manufatura em várias fases do ciclo de vida do produto. A análise de efeitos refere-se ao estudo das consequências dessas falhas em diferentes níveis do sistema.

As análises funcionais são necessárias como uma entrada para determinar os modos de falha corretos, em todos os níveis do sistema, para FMEA funcional ou FMEA de peça-peça (hardware). Um FMEA é usado para estruturar a redução de Mitigação para Risco com base na redução da gravidade do efeito de falha (modo) ou com base na redução da probabilidade de falha ou ambos. O FMEA é, em princípio, uma análise totalmente indutiva (lógica direta), no entanto, a probabilidade de falha só pode ser estimada ou reduzida pela compreensão do mecanismo de falha . Portanto, o FMEA pode incluir informações sobre as causas da falha (análise dedutiva) para reduzir a possibilidade de ocorrência, eliminando as causas identificadas (raiz) .

Introdução

O FME (C) A é uma ferramenta de projeto usada para analisar sistematicamente as falhas postuladas de componentes e identificar os efeitos resultantes nas operações do sistema. A análise às vezes é caracterizada como consistindo em duas subanálises, sendo a primeira os modos de falha e análise de efeitos (FMEA), e a segunda, a análise de criticidade (CA). O desenvolvimento bem-sucedido de um FMEA requer que o analista inclua todos os modos de falha significativos para cada elemento ou parte contribuinte do sistema. FMEAs podem ser executados no nível do sistema, subsistema, montagem, submontagem ou peça. O FMECA deve ser um documento vivo durante o desenvolvimento de um projeto de hardware. Deve ser programado e concluído simultaneamente com o projeto. Se concluído em tempo hábil, o FMECA pode ajudar a orientar as decisões de projeto. A utilidade do FMECA como ferramenta de projeto e no processo de tomada de decisão depende da eficácia e oportunidade com que os problemas de projeto são identificados. A oportunidade é provavelmente a consideração mais importante. Em casos extremos, o FMECA teria pouco valor para o processo de decisão do projeto se a análise fosse realizada após a construção do hardware. Embora o FMECA identifique todos os modos de falha de peça, seu benefício principal é a identificação precoce de todos os subsistemas críticos e catastróficos ou modos de falha do sistema para que possam ser eliminados ou minimizados por meio de modificação de projeto no ponto mais inicial do esforço de desenvolvimento; portanto, o FMECA deve ser executado no nível do sistema assim que as informações do projeto preliminar estiverem disponíveis e estendido para os níveis inferiores conforme o projeto detalhado progride.

Observação: Para uma modelagem de cenário mais completa, outro tipo de análise de confiabilidade pode ser considerado, por exemplo , análise de árvore de falha (FTA); uma análise de falha dedutiva (lógica reversa) que pode lidar com várias falhas dentro do item e / ou externas ao item, incluindo manutenção e logística. Ele começa em um nível funcional / de sistema superior. Um FTA pode usar os registros FMEA do modo de falha básico ou um resumo de efeito como uma de suas entradas (os eventos básicos). Análise de risco de interface, análise de erro humano e outros podem ser adicionados para conclusão na modelagem de cenário.

Modo de falha funcional e análise de efeitos

A análise deve sempre ser iniciada listando as funções que o projeto precisa cumprir. As funções são o ponto de partida de um FMEA bem executado e o uso de funções como linha de base fornece o melhor rendimento de um FMEA. Afinal, um design é apenas uma das soluções possíveis para executar funções que precisam ser cumpridas. Desta forma, um FMEA pode ser feito em projetos de conceito, bem como em projetos detalhados, em hardware e software, e não importa o quão complexo seja o projeto.

Ao executar um FMECA, o hardware de interface (ou software) é considerado primeiro como operando dentro das especificações. Depois disso, ele pode ser estendido, conseqüentemente, usando um dos 5 modos de falha possíveis de uma função do hardware de interface como uma causa de falha para o elemento de design em análise. Isso dá a oportunidade de tornar o projeto robusto para falha de função em outras partes do sistema.

Além disso, cada falha de peça postulada é considerada a única falha no sistema (ou seja, é uma análise de falha única). Além dos FMEAs feitos nos sistemas para avaliar o impacto que as falhas de nível inferior têm na operação do sistema, vários outros FMEAs são feitos. Atenção especial é dada às interfaces entre os sistemas e, de fato, a todas as interfaces funcionais. O objetivo desses FMEAs é garantir que danos físicos e / ou funcionais irreversíveis não sejam propagados pela interface como resultado de falhas em uma das unidades de interface. Essas análises são feitas no nível da peça para os circuitos que fazem interface direta com as outras unidades. O FMEA pode ser realizado sem um CA, mas um CA requer que o FMEA identificou previamente as falhas críticas de nível de sistema. Quando ambas as etapas são realizadas, o processo total é denominado FMECA.

Regras básicas

As regras básicas de cada FMEA incluem um conjunto de procedimentos selecionados do projeto; as suposições nas quais a análise se baseia; o hardware que foi incluído e excluído da análise e a justificativa para as exclusões. As regras básicas também descrevem o nível de escritura da análise (ou seja, o nível na hierarquia da parte para o subsistema, subsistema para o sistema, etc.), o status do hardware básico e os critérios para o sistema e a missão sucesso. Todo esforço deve ser feito para definir todas as regras básicas antes do início do FMEA; no entanto, as regras básicas podem ser expandidas e esclarecidas à medida que a análise prossegue. Um conjunto típico de regras básicas (suposições) segue:

1. Existe apenas um modo de falha por vez.
2. Todas as entradas (incluindo comandos de software) para o item que está sendo analisado estão presentes e em valores nominais.
3. Todos os consumíveis estão presentes em quantidades suficientes.
4. A potência nominal está disponível

Benefícios

Os principais benefícios derivados de um esforço FMECA implementado adequadamente são os seguintes:

1. Ele fornece um método documentado para selecionar um projeto com alta probabilidade de operação bem-sucedida e segurança.
2. Um método uniforme documentado de avaliação de mecanismos de falha em potencial, modos de falha e seu impacto na operação do sistema, resultando em uma lista de modos de falha classificados de acordo com a gravidade do impacto do sistema e a probabilidade de ocorrência.
3. Identificação antecipada de pontos de falha única (SFPS) e problemas de interface do sistema, que podem ser críticos para o sucesso e / ou segurança da missão. Eles também fornecem um método para verificar se a comutação entre elementos redundantes não é prejudicada por falhas únicas postuladas.
4. Um método eficaz para avaliar o efeito das alterações propostas no projeto e / ou procedimentos operacionais sobre o sucesso e a segurança da missão.
5. Uma base para procedimentos de solução de problemas em vôo e para localização de monitoramento de desempenho e dispositivos de detecção de falhas.
6. Critérios para planejamento antecipado de testes.

Da lista acima, as identificações iniciais de SFPS, a entrada para o procedimento de solução de problemas e a localização de dispositivos de monitoramento de desempenho / detecção de falhas são provavelmente os benefícios mais importantes do FMECA. Além disso, os procedimentos do FMECA são diretos e permitem uma avaliação ordenada do projeto.

História

Os procedimentos para a condução de FMECA foram descritos no documento de Procedimentos Militares das Forças Armadas dos EUA MIL-P-1629 (1949); revisado em 1980 como MIL-STD-1629A. No início dos anos 1960, os empreiteiros da Administração Nacional de Aeronáutica e Espaço (NASA) dos Estados Unidos usavam variações do FMECA ou FMEA sob diversos nomes. Os programas da NASA que usam variantes FMEA incluem Apollo , Viking , Voyager , Magellan , Galileo e Skylab . A indústria da aviação civil foi uma das primeiras a adotar o FMEA, com a Society for Automotive Engineers (SAE, uma organização que cobre a aviação e outros transportes além do automotivo, apesar do nome) publicando o ARP926 em 1967. Após duas revisões, a Prática Recomendada Aeroespacial ARP926 foi substituído pelo ARP4761 , que agora é amplamente utilizado na aviação civil.

Durante a década de 1970, o uso de FMEA e técnicas relacionadas se espalhou para outras indústrias. Em 1971, a NASA preparou um relatório para o US Geological Survey, recomendando o uso de FMEA na avaliação da exploração de petróleo offshore. Um relatório de 1973 da Agência de Proteção Ambiental dos EUA descreveu a aplicação da FMEA em estações de tratamento de águas residuais. FMEA como aplicativo para HACCP no Programa Espacial Apollo mudou-se para a indústria de alimentos em geral.

A indústria automotiva começou a usar FMEA em meados dos anos 1970. A Ford Motor Company apresentou FMEA para a indústria automotiva para a segurança e consideração regulamentar após o caso de Pinto . A Ford aplicou a mesma abordagem de processos (PFMEA) para considerar possíveis falhas induzidas por processo antes de iniciar a produção. Em 1993, o Automotive Industry Action Group (AIAG) publicou pela primeira vez um padrão FMEA para a indústria automotiva. Já está em sua quarta edição. O SAE publicou pela primeira vez o padrão relacionado J1739 em 1994. Este padrão também está em sua quarta edição. Em 2019, as duas descrições dos métodos foram substituídas pelo novo manual AIAG / VDA FMEA. É uma harmonização das antigas normas FMEA de AIAG, VDA , SAE e outras descrições de métodos.

Embora inicialmente desenvolvida pelos militares, a metodologia FMEA é agora amplamente usada em uma variedade de indústrias, incluindo processamento de semicondutores, serviços de alimentação, plásticos, software e saúde. A Toyota deu um passo adiante com sua abordagem de Revisão de Projeto com Base no Modo de Falha (DRBFM). O método agora é apoiado pela American Society for Quality, que fornece guias detalhados sobre a aplicação do método. Os procedimentos padrão de Análise de Modos e Efeitos de Falha (FMEA) e Modos de Falha, Efeitos e Análise de Criticidade (FMECA) identificam os mecanismos de falha do produto, mas não podem modelá-los sem um software especializado. Isso limita sua aplicabilidade para fornecer uma entrada significativa para procedimentos críticos, como qualificação virtual, análise de causa raiz, programas de teste acelerado e avaliação de vida restante. Para superar as deficiências do FMEA e do FMECA, um Modos de Falha, Mecanismos e Análise de Efeito (FMMEA) tem sido freqüentemente usado.

Termos básicos

O seguinte cobre algumas terminologias básicas de FMEA.

Prioridade de ação (AP)

O AP substitui a antiga matriz de risco e RPN no manual AIAG / VDA FMEA 2019. Ele faz uma declaração sobre a necessidade de medidas de melhoria adicionais.

Fracasso

A perda de uma função nas condições estabelecidas.

Modo de falha

A maneira ou maneira específica pela qual uma falha ocorre em termos de falha da peça, componente, função, equipamento, subsistema ou sistema sob investigação. Dependendo do tipo de FMEA realizado, o modo de falha pode ser descrito em vários níveis de detalhes. A FMEA de uma peça focará em modos de falha de peça ou componente detalhados (como eixo totalmente fraturado ou eixo deformado, ou contato elétrico travado aberto, travado curto ou intermitente). Um FMEA funcional se concentrará nos modos de falha funcional. Eles podem ser gerais (como Sem função, Sobre função, Subfunção, Função intermitente ou Função não intencional) ou mais detalhados e específicos para o equipamento que está sendo analisado. Um PFMEA se concentrará nos modos de falha do processo (como inserir a broca errada).

Causa da falha e / ou mecanismo

Defeitos em requisitos, design, processo, controle de qualidade, manuseio ou aplicação de peças, que são a causa subjacente ou sequência de causas que iniciam um processo (mecanismo) que leva a um modo de falha ao longo de um determinado tempo. Um modo de falha pode ter mais causas. Por exemplo; "fadiga ou corrosão de uma viga estrutural" ou "corrosão por contato em um contato elétrico" é um mecanismo de falha e em si (provavelmente) não é um modo de falha. O modo de falha relacionado (estado final) é uma "fratura total da viga estrutural" ou "um contato elétrico aberto". A causa inicial pode ter sido "Aplicação inadequada da camada de proteção contra corrosão (tinta)" e / ou "entrada de vibração (anormal) de outro sistema (possivelmente com falha)".

Efeito de falha

Consequências imediatas de uma falha na operação, ou mais geralmente nas necessidades do cliente / usuário que deveriam ser atendidas pela função, mas agora não são, ou não são totalmente atendidas

Níveis de escritura (lista de materiais ou repartição funcional)

Um identificador para o nível do sistema e, portanto, para a complexidade do item. A complexidade aumenta à medida que os níveis se aproximam de um.

Efeito local

O efeito de falha conforme se aplica ao item em análise.

Efeito de próximo nível superior

O efeito de falha conforme se aplica ao próximo nível de escritura superior.

Efeito final

O efeito de falha no nível de escritura mais alto ou sistema total.

Detecção

Os meios de detecção do modo de falha pelo mantenedor, operador ou sistema de detecção embutido, incluindo o período de dormência estimado (se aplicável)

Probabilidade

A probabilidade de ocorrência da falha.

Número de prioridade de risco (RPN)

Gravidade (do evento) × Probabilidade (da ocorrência do evento) × Detecção (probabilidade de que o evento não seja detectado antes que o usuário tenha conhecimento)

Gravidade

As consequências de um modo de falha. A gravidade considera a pior consequência potencial de uma falha, determinada pelo grau de lesão, dano à propriedade, dano ao sistema e / ou tempo perdido para reparar a falha.

Observações / mitigação / ações

Informações adicionais, incluindo a mitigação proposta ou ações usadas para reduzir um risco ou justificar um nível ou cenário de risco.

Exemplo de planilha FMEA

Probabilidade (P)

É necessário examinar a causa de um modo de falha e a probabilidade de ocorrência. Isso pode ser feito por análise, cálculos / FEM, olhando para itens ou processos semelhantes e os modos de falha que foram documentados para eles no passado. Uma causa de falha é vista como uma fraqueza do projeto. Todas as causas potenciais para um modo de falha devem ser identificadas e documentadas. Isso deve ser em termos técnicos. Exemplos de causas são: Erros humanos no manuseio, Falhas induzidas pela fabricação, Fadiga, Deformação, Desgaste abrasivo, algoritmos errôneos, tensão excessiva ou condições de operação ou uso inadequados (dependendo das regras básicas usadas). Um modo de falha pode receber uma classificação de probabilidade com um número definido de níveis.

Para uma FMEA de parte de peça, a probabilidade quantitativa pode ser calculada a partir dos resultados de uma análise de previsão de confiabilidade e as taxas de modo de falha de um catálogo de distribuição de modo de falha, como RAC FMD-97. Este método permite que um FTA quantitativo use os resultados do FMEA para verificar se os eventos indesejados atendem aos níveis aceitáveis ​​de risco.

Gravidade (S)

Determine a Severidade para o efeito final adverso (estado) do pior cenário. É conveniente escrever esses efeitos em termos do que o usuário pode ver ou experimentar em termos de falhas funcionais. Exemplos desses efeitos finais são: perda total da função x, desempenho degradado, funções no modo reverso, funcionamento muito tarde, funcionamento errático, etc. Cada efeito final recebe um número de Severidade (S) de, digamos, I (sem efeito) a V (catastrófico), com base no custo e / ou perda de vida ou qualidade de vida. Esses números priorizam os modos de falha (junto com probabilidade e detectabilidade). Abaixo, é fornecida uma classificação típica. Outras classificações são possíveis. Veja também análise de risco .

Detecção (D)

O meio ou método pelo qual uma falha é detectada, isolado pelo operador e / ou mantenedor e o tempo que pode levar. Isso é importante para o controle de manutenção (disponibilidade do sistema) e é especialmente importante para vários cenários de falha. Isso pode envolver modos de falha latentes (por exemplo, nenhum efeito direto do sistema, enquanto um sistema / item redundante assume automaticamente ou quando a falha só é problemática durante a missão específica ou estados do sistema) ou falhas latentes (por exemplo , mecanismos de falha de deterioração , como uma rachadura crescente de metal , mas não um comprimento crítico). Deve ficar claro como o modo ou causa da falha pode ser descoberto por um operador durante a operação normal do sistema ou se pode ser descoberto pela equipe de manutenção por alguma ação de diagnóstico ou teste automático do sistema integrado. Um período de dormência e / ou latência pode ser inserido.

Dormência ou período de latência

O tempo médio que um modo de falha pode não ser detectado pode ser inserido, se conhecido. Por exemplo:

• Segundos, detectado automaticamente pelo computador de manutenção
• 8 horas, detectado por inspeção de retorno
• 2 meses, detectado pelo bloco de manutenção programada X
• 2 anos, detectado pela tarefa de revisão x

Indicação

Se a falha não detectada permitir que o sistema permaneça em um estado de segurança / funcionamento, uma segunda situação de falha deve ser explorada para determinar se uma indicação será ou não evidente para todos os operadores e que ação corretiva eles podem ou devem tomar.

As indicações para o operador devem ser descritas da seguinte forma:

• Normal. Uma indicação que é evidente para um operador quando o sistema ou equipamento está operando normalmente.
• Anormal. Uma indicação que é evidente para um operador quando o sistema apresenta mau funcionamento ou falha.
• Incorreta. Uma indicação errada para um operador devido ao mau funcionamento ou falha de um indicador (ou seja, instrumentos, dispositivos de detecção, dispositivos de advertência visuais ou sonoros, etc.).

REALIZAR ANÁLISE DE COBERTURA DE DETECÇÃO PARA PROCESSOS DE TESTE E MONITORAMENTO (do padrão ARP4761):

Este tipo de análise é útil para determinar a eficácia de vários processos de teste na detecção de falhas latentes e latentes. O método usado para fazer isso envolve um exame dos modos de falha aplicáveis ​​para determinar se seus efeitos são ou não detectados e para determinar a porcentagem da taxa de falha aplicável aos modos de falha que são detectados. A possibilidade de que os próprios meios de detecção possam falhar latentemente deve ser considerada na análise de cobertura como um fator limitante (ou seja, a cobertura não pode ser mais confiável do que a disponibilidade dos meios de detecção). A inclusão da cobertura de detecção no FMEA pode levar a cada falha individual que teria sido uma categoria de efeito sendo agora uma categoria de efeito separada devido às possibilidades de cobertura de detecção. Outra maneira de incluir a cobertura de detecção é o FTA assumir, de maneira conservadora, que nenhuma falha na cobertura devido a falha latente no método de detecção afeta a detecção de todas as falhas atribuídas à categoria de efeito de falha de interesse. O FMEA pode ser revisado, se necessário, para os casos em que essa premissa conservadora não permite que os principais requisitos de probabilidade de evento sejam atendidos.

Após essas três etapas básicas, o nível de risco pode ser fornecido.

Nível de risco (P × S) e (D)

Risco é a combinação de Probabilidade e Gravidade do Efeito Final, em que a probabilidade e a gravidade incluem o efeito na não detectabilidade ( tempo de dormência ). Isso pode influenciar a probabilidade de falha do efeito final ou o pior caso de Gravidade do efeito. O cálculo exato pode não ser fácil em todos os casos, como aqueles em que vários cenários (com vários eventos) são possíveis e a detectabilidade / dormência desempenha um papel crucial (como para sistemas redundantes). Nesse caso, a análise da árvore de falhas e / ou árvores de eventos pode ser necessária para determinar a probabilidade exata e os níveis de risco.

Os níveis de risco preliminar podem ser selecionados com base em uma matriz de risco como mostrado abaixo, com base em Mil. Padrão 882. Quanto mais alto o nível de risco, mais justificativa e mitigação são necessárias para fornecer evidências e reduzir o risco a um nível aceitável. O alto risco deve ser indicado para gerências de nível superior, que são responsáveis ​​pela tomada de decisão final.

• Após esta etapa, o FMEA se tornou como um FMECA .

Cronometragem

O FMEA deve ser atualizado sempre que:

• Um novo ciclo começa (novo produto / processo)
• Mudanças são feitas nas condições operacionais
• Uma mudança é feita no design
• Novos regulamentos são instituídos
• O feedback do cliente indica um problema

Usos

• Desenvolvimento de requisitos de sistema que minimizam a probabilidade de falhas.
• Desenvolvimento de projetos e sistemas de teste para garantir que as falhas sejam eliminadas ou o risco seja reduzido a um nível aceitável.
• Desenvolvimento e avaliação de sistemas de diagnóstico
• Para ajudar nas escolhas de design (análise de trade-off).

Vantagens

• Catalisador para trabalho em equipe e troca de ideias entre funções
• Colete informações para reduzir falhas futuras, capture conhecimento de engenharia
• Identificação antecipada e eliminação de modos de falha em potencial
• Enfatize a prevenção de problemas
• Cumprir os requisitos legais (responsabilidade do produto)
• Melhore a imagem e a competitividade da empresa
• Melhorar o rendimento da produção
• Melhorar a qualidade, confiabilidade e segurança de um produto / processo
• Aumente a satisfação do usuário
• Maximize o lucro
• Minimize as mudanças atrasadas e os custos associados
• Reduza o impacto na margem de lucro da empresa
• Reduza o tempo e o custo de desenvolvimento do sistema
• Reduza a possibilidade do mesmo tipo de falha no futuro
• Reduza o potencial de questões de garantia

Limitações

Embora o FMEA identifique perigos importantes em um sistema, seus resultados podem não ser abrangentes e a abordagem tem limitações. No contexto da saúde, FMEA e outros métodos de avaliação de risco, incluindo SWIFT ( Structured What If Technique ) e abordagens retrospectivas, têm validade limitada quando usados ​​isoladamente. Desafios em torno de escopo e limites organizacionais parecem ser um fator importante nesta falta de validade.

Se usado como uma ferramenta de cima para baixo , o FMEA pode apenas identificar os principais modos de falha em um sistema. A análise da árvore de falhas (FTA) é mais adequada para análise "de cima para baixo". Quando usado como uma ferramenta "de baixo para cima", o FMEA pode aumentar ou complementar o FTA e identificar muitas outras causas e modos de falha, resultando em sintomas de nível superior. Ele não é capaz de descobrir modos de falha complexos envolvendo várias falhas dentro de um subsistema, ou relatar intervalos de falha esperados de modos de falha específicos até o subsistema ou sistema de nível superior.

Além disso, a multiplicação das classificações de gravidade, ocorrência e detecção pode resultar em reversões de classificação, onde um modo de falha menos sério recebe um RPN mais alto do que um modo de falha mais sério. A razão para isso é que as classificações são números de escala ordinal e a multiplicação não é definida para números ordinais. As classificações ordinais apenas dizem que uma classificação é melhor ou pior do que outra, mas não por quanto. Por exemplo, uma classificação de "2" pode não ser duas vezes mais severa que uma classificação de "1", ou um "8" pode não ser duas vezes mais severo que um "4", mas a multiplicação os trata como se fossem. Consulte Nível de medição para uma discussão mais detalhada. Várias soluções para este problema têm sido propostas, por exemplo, o uso da lógica fuzzy como alternativa ao modelo RPN clássico. No novo manual AIAG / VDA FMEA (2019), a abordagem RPN foi substituída pela AP (prioridade de ação).

A planilha FMEA é difícil de produzir, difícil de entender e ler, bem como difícil de manter. O uso de técnicas de rede neural para agrupar e visualizar modos de falha foi sugerido a partir de 2010. Uma abordagem alternativa é combinar a tabela FMEA tradicional com um conjunto de diagramas de gravata borboleta. Os diagramas fornecem uma visualização das cadeias de causa e efeito, enquanto a tabela FMEA fornece informações detalhadas sobre eventos específicos.

Tipos

• Funcional : antes que as soluções de projeto sejam fornecidas (ou apenas em alto nível), as funções podem ser avaliadas sobre os efeitos de falha funcional em potencial. Mitigações gerais (requisitos de "design para") podem ser propostas para limitar a consequência de falhas funcionais ou limitar a probabilidade de ocorrência neste desenvolvimento inicial. Baseia-se na repartição funcional de um sistema. Este tipo também pode ser usado para avaliação de software.
• Projeto Conceitual / Hardware : análise de sistemas ou subsistemas nos estágios iniciais do conceito de projeto para analisar os mecanismos de falha e falhas funcionais de nível inferior, especialmente para diferentes soluções de conceito em mais detalhes. Pode ser usado em estudos de trade-off.
• Projeto Detalhado / Hardware : análise de produtos antes da produção. Estes são os FMEAs mais detalhados (no MIL 1629 chamados Piece-Part ou Hardware FMEA) e usados ​​para identificar qualquer possível modo de falha de hardware (ou outro) até o nível de peça mais baixo. Deve ser baseado na quebra de hardware (por exemplo, BoM = Lista de Materiais). Qualquer efeito de falha Severidade, Prevenção de falha (Mitigação), Detecção de Falhas e Diagnósticos podem ser totalmente analisados ​​neste FMEA.
• Processo : análise dos processos de fabricação e montagem. Tanto a qualidade quanto a confiabilidade podem ser afetadas por falhas no processo. A entrada para este FMEA é, entre outros, um detalhamento do processo de trabalho / tarefa.

Veja também

Referências