Falando de FMEA

Postado por Mauricio Dorneles

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;

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 )

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.

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


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.

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


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.

Obrigado.
















0 comentários: