Resumo Sobre FMEA Nota Data
Aluno: Professor
Izaque
Análise de Modo de Falha e seus Efeitos – FMEA - Projeto & Processo
Histórico
O FMEA é utilizada há muito tempo. Não havia no início uma sistemática estabelecida nem um
formato de documento, e a maioria dos inventores e especialistas em processos tentavam
antecipar o que poderia dar errado num projeto ou processo antes de ser desenvolvido. A adoção
da prática da “tentativa e erro” custava muito e consumia muito tempo.
O FMEA foi introduzida formalmente no final dos anos 40 com a emissão da norma militar
(military standard) 1629. Usada pela indústria aeroespacial no desenvolvimento de foguetes, a
FMEA e mais detalhadamente a FMECA (C = crítico) foi bastante útil em evitar erros na
dispendiosa tecnologia dos foguetes.
O que é o FMEA?
O FMEA é uma abordagem sistêmica que identifica potenciais modos de falha num sistema,
produto ou operação de manufatura/montagem ocasionada por deficiência tanto no projeto
quanto nos processos de manufatura/montagem. Também identifica características críticas ou
significantes no projeto ou processo que requerem controles especiais que previnem ou detectam
modos de falhas.
O FMEA é uma ferramenta usada para prevenir a ocorrência de problemas. Em adição, a divisão
de alimentos e remédios americana (FDA) reconhece a FMEA como um método para verificação
de riscos em projetos de remédios e dispositivos médicos.
Uma FMEA pode ser descrita como sendo um grupo sistemático de atividades destinadas a:
Reconhecer e avaliar a falha potencial de um produto/processo e os efeitos desta falha,
Identificar ações que poderiam eliminar ou reduzir a possibilidade de ocorrência de uma
falha potencial, e
Documentar todo o processo de definição do que o projeto ou o processo deve fazer para
satisfazer o cliente.
Todas os FMEA’s possuem enfoque no projeto, quer seja do produto ou do processo.
Um FMEA não deveria ser o simples ato de preencher um formulário, mas preferencialmente o
entendimento de que este é um processo para eliminar riscos e planejar os controles apropriados
para assegurar a satisfação do cliente.
Um dos fatores mais importantes para a implementação de um programa de FMEA é o momento
oportuno de sua execução. Um FMEA:
Deve ser uma ação “antes-do-evento”, e não um exercício “após-o-fato”;
Deve ser incorporada ao projeto do produto ou processo;
Deve ser executada quando as alterações no projeto do produto/processo possam ser
implementadas mais facilmente e com menores custos;
1
Pode reduzir ou eliminar a chance de implementar uma alteração preventiva/corretiva que
poderia criar um problema ainda maior.
Um FMEA de Projeto é uma técnica analítica usada fundamentalmente pelo Engenheiro/Equipe
Responsável pelo Projeto do Produto com a finalidade de assegurar que, na extensão possível,
os modos de falha potenciais e suas causas/mecanismos associados foram considerados e
abordados.
Um FMEA de Processo é uma técnica analítica usada pelo Engenheiro/Equipe Responsável pela
Manufatura/Montagem com a finalidade de assegurar que, na extensão possível, os modos de
falha potenciais e suas causas/mecanismos associados foram considerados e abordados.
Em uma forma mais precisa, um FMEA de Projeto é um resumo dos pensamentos da equipe de
como um componente, subsistema ou sistema é projetado (incluindo uma análise dos itens que
poderiam dar errados baseados na experiência). Esta abordagem sistemática acompanha,
formaliza e documenta a linha de pensamento que é normalmente percorrida durante o
desenvolvimento de um Projeto de Produto.
Em uma forma mais precisa, um FMEA de Processo é um resumo dos pensamentos da equipe
durante o desenvolvimento de um processo e inclui a análise de itens que poderiam falhar
baseados na experiência e nos problemas passados. Esta abordagem sistemática acompanha,
formaliza e documenta a linha de pensamento que é normalmente percorrida durante o processo
de planejamento da Manufatura.
Índices de Avaliação
Cada modo de falha é pontuado com base em tabelas específicas, que quantificam:
O quão perigoso ou danoso a falha poderá ser para uma pessoa ou equipamento (Índice de
Severidade – “S”);
Qual a probabilidade de a falha acontecer (Índice de Ocorrência- “O”);
Qual a probabilidade de se detectar a falha (Índice de Detecção – “D”).
O produto destes índices gera o Número de Prioridade de Risco – “NPR”.
Dentro do escopo de uma FMEA individual, este valor (que se situa entre 1 e 1000) pode ser
utilizado para priorizar as ações sobre as deficiências do projeto do produto/processo, conforme
sugestão abaixo:
Baixo risco = 1 a 135 Risco moderado = 136 a 600 Alto risco = 601 a 1000
( Você pode definir a sua pontuação e classificação )
2
Um FMEA deveria ser realizada conforme a seqüência:
Todo FMEA deveria ter um documento de hipóteses anexado (eletronicamente se possível) ou a
primeira linha do FMEA deveria detalhar as hipóteses e índices usados no FMEA.
O nome e número do Produto devem ser inseridos no cabeçalho da FMEA.
Todos os membros da equipe devem ser listados no FMEA.
A data de revisão, conforme apropriado, deve ser documentada no cabeçalho do FMEA.
Função
A função deveria ser escrita numa frase.
Cada função deve ter dimensões mensuráveis associadas.
EXEMPLO:
O sistema de ar-condicionado deve desembaçar as janelas e aquecer ou resfriar o interior do
veículo em todas as condições operacionais (-40 a 90 ºC)
- Num intervalo de 3 a 5 minutos ou
- Conforme requisito funcional nº_______; revisão/data_________
O modo de falha deveria ser descrito numa frase.
Também deve ser descrito como sendo a “anti-função”.
Há 5 tipos de modos de falhas: falha completa, falha parcial, falha intermitente, sobre-função, e
função não-intencional.
3
EXEMPLOS:
Sistema de ar-condicionado não aquece o interior do veículo ou desembaça as janelas
Sistema de ar-condicionado leva mais do que 5 minutos para aquecer o interior do veículo
Sistema de ar-condicionado aquece o interior do veículo até 10ºC máximo em temperaturas
abaixo de zero
Sistema de ar-condicionado refrigera o interior do veículo até 5ºC
Sistema de ar-condicionado ativa desembaçador traseiro
Os efeitos deveriam ser listados sob o ponto de vista do cliente.
Os efeitos devem incluir (conforme apropriado) requisitos de segurança/regulamental, finalidade
de uso, funcionários da manufatura, montagem, serviços.
EXEMPLO:
Não é possivel ver o lado de fora do veículo
Ar-condicionado refrigera demais o interior do veículo
Não ocorre aquecimento suficiente
Leva tempo demais para aquecer
Os valores da severidade devem ser estabelecidos.
Se a severidade for baseada em critérios definidos internamente ou em alguma norma específica,
uma referência à tabela de índices com explicações sobre o uso da mesma deve ser
estabelecido.
EXEMPLO:
Não é possivel ver o lado de fora do veículo – severidade 9
Ar-condicionado refrigera demais o interior do veículo – severidade 5
Não ocorre aquecimento suficiente – severidade 5
Leva tempo demais para aquecer – severidade 4
4
A classificação deve ser usada para definir características significativas e potencialmente críticas.
Características críticas (9 ou 10 em severidade com 2 ou mais em ocorrência - sugerido)
deveriam ter ações recomendadas associadas.
Características significativas (4 a 8 em severidade com 4 ou mais em ocorrência - sugerido)
deveriam ter ações recomendadas associadas.
A classificação deveria ter critérios definedos para aplicação.
EXEMPLO:
Não é possível ver o lado de fora do veículo – severidade 9 / Localização incorreta do defletor de
ar – ocorrência 2
Ar-condicionado refrigera demais o interior do veículo – severidade 5 / Posição incorreta da
tubulação de ventilação (muito afastada da fonte de aquecimento) – ocorrência 6
As causas deveriam ser limitadas a questões relacionadas ao projeto.
As análises devem se situar dentro do escopo definido (sistemas aplicáveis e interfaces com
sistemas adjacentes).
As análises de causas relacionadas a componentes deveriam ser consideradas como as de um
produto.
Há usualmente mais de uma causa para cada modo de falha.
As causas devem ser identificadas para um modo de falha, e não para o efeito da falha.
EXEMPLO:
Localização incorreta dos defletores de ar
Posição incorreta da tubulação de ventilação (muito afastada da fonte de aquecimento)
Capacidade de refrigeração inadequada do líquido (“coolant”)
Os valores de ocorrência devem ser estabelecidos.
Se a severidade for baseada em critérios definidos internamente ou em alguma norma específica,
uma referência a tabela de índices com explicações sobre o uso da mesma deve ser
estabelecido.
Os índices de ocorrência para a FMEA são baseados na probabilidade de que a causa venha
ocorrer, nas falhas ocorridas ou no desempenho de sistemas similares.
5
EXEMPLO:
Localização incorreta dos defletores de ar – ocorrência 2
Posição incorreta da tubulação de ventilação (muito afastada da fonte de aquecimento) –
ocorrência 3
Capacidade de refrigeração inadequada do líquido (“coolant”) – ocorrência 6
Controles preventivos são aqueles que auxiliam na redução da probabilidade de que o modo de
falha ou sua causa ocorram – afeta o valor da ocorrência.
Controles detectivos são aqueles que evidenciam problemas que tenham acontecido no projeto
do produto/processo – determina o valor da detecção.
EXEMPLO:
Especificações de engenharia (P) – controle preventivo
Dados históricos (P) – controle preventivo
Teste funcional (D) – controle detectivo
Durabilidade geral do produto (D) – controle detectivo
Os valores de detecção devem ser estabelecidos.
Se a detecção for baseada em critérios definidos internamente ou em alguma norma específica,
uma referência a tabela de índices com explicações sobre o uso da mesma deve ser
estabelecido.
A detecção é o valor determinado para cada controle identificado.
O valor de detecção 1 elimina a potencialidade de falhas decorrentes de deficiência de projeto.
EXEMPLO:
Especificação de engenharia – nenhum valor para detecção
Dados historicos – nenhum valor para detecção
Teste funcional – detecção 3
Durabilidade geral do produto – detecção 5
6
O Número de Prioridade de Risco (NPR) é a multiplicação dos índices de severidade, ocorrência
e detecção.
Índices mais baixos de detecção são usados para determinar RPN.
O NPR por si só não deve ser usado como um referencial primário de definição de ações
recomendadas.
EXEMPLO:
Não é possível ver o lado de fora do veículo – severidade 9, – Localização incorreta dos
defletores de ar – ocorrência 2, Teste funcional – detecção 3, RPN – 54
Todas as características críticas ou significantes devem ter ações recomendadas associadas.
Ações recomendadas deveriam ser focadas no projeto (produto/processo), e direcionada no
sentido de minimizar a causa da falha, ou eliminar o modo de falha.
Se as ações recomendadas não conseguirem minimizar ou eliminar a potencialidade da falha no
projeto do produto, novas ações devem forçar a inserção da característica no FMEA de processo
a fim de obter o intento anterior.
Todas as ações recomendadas devem ter uma pessoa designada como responsável para
implementá-las e outra para verificar a implementação das ações.
A definição das responsabilidades deve discriminar o nome da pessoa e não o cargo.
A pessoa designada como responsável por uma ação deve ser também um membro da equipe
para solução do problema.
Deve haver uma data para a implementação de cada ação recomendada.
Ações adotadas devem detalhar o que foi feito e os resultados das mesmas.
Ações deve ser completada pela data efetiva de implementação.
A não ser que o modo de falha tenha sido eliminado, a severidade não deveria mudar.
A ocorrência deve ou não ser diminuída com base no resultado das ações.
A detecção deve ou não ser diminuída com base no resultado das ações.
Se os índices de severidade, ocorrência ou detecção não melhorarem, a recomendação de ações
adicionais deve ser definida.
