Allef Pereira de Jesus_3205N - SWOT

Prévia do material em texto

CENTRO UNIVERSITÁRIO UNIFACVEST 
ENGENHARIA DE PRODUÇÃO
ALLEF PEREIRA DE JESUS
IVANES JUNIOR
GABRIEL PEREIRA
FMEA – FAILURE MODE AND EFFECT ANALYSIS
LAGES
2018
ALLEF PEREIRA DE JESUS
IVANES JUNIOR
GABRIEL PEREIRA 
FMEA – FAILURE MODE AND EFFECT ANALYSIS
Trabalho apresentado ao Centro Universitário UNIFACVEST, como parte dos requisitos para a avaliação da disciplina de (Manutenção Industrial), da turma 3208N.
Prof. Alisson Ribeiro de Oliveira.
LAGES
2018
 
FMEA – FAILURE MODE AND EFFECT ANALYSIS
Allef Pereira de Jesus¹
Ivanes Junior²
Gabriel Pereira³
Alisson Ribeiro de Oliveira
RESUMO 
Este artigo tem como objetivo fornecer uma visão ampla e superficial do FMEA, possibilitando ao usuário ter noções de como, quando e porquê aplicar o método e fornecer informações sobre as limitações do método e dicas para evitar erros na execução do mesmo.
Palavras-chave: fmea, método, execução.
 
1 O QUE É O FMEA
FMEA (Failure Mode and Effect Analysis) é uma ferramenta usada para aumentar a confiabilidade de um certo produto durante a fase de projeto ou processo. A ferramenta consiste basicamente em sistematizar um grupo de atividades para detectar possíveis falhas e avaliar os efeitos das mesmas para o projeto/processo. A partir dessas possíveis falhas, identificam-se ações a serem tomadas para eliminar ou reduzir a probabilidade de que as mesmas ocorram. Essas ações também podem objetivar aumentar a probabilidade de detecção dessas falhas, para que os produtos que apresentam inconformidades não cheguem ao cliente.
Deste modo é obtida uma lista de possíveis falhas, organizada por ordem do risco que elas representam e com respectivas ações a serem tomadas para mitigá-las. Essa lista auxilia na escolha de projetos alternativos com alta confiabilidade durante as etapas iniciais da fase de projeto. Assim garante-se que todas as possíveis falhas de um projeto/processos sejam consideradas e suas probabilidades de ocorrência minimizadas (quando se fizer necessário).
2 TIPOS DE FMEA
Geralmente é aceito que existem quatro tipos de FMEA’s. As etapas e a maneira de realização da análise são as mesmas, diferenciando-se principalmente quanto ao objetivo. Desta maneira, temos:
FMEA de design: São consideradas as falhas que poderão ocorrer com o produto dentro das especificações do projeto. O objetivo desta análise é evitar falhas no produto ou no processo decorrentes do projeto. É comumente denominada também de FMEA de projeto ou produto
FMEA de processos: São consideradas as falhas no planejamento e execução do processo, ou seja, o objetivo desta análise é evitar falhas do processo, tendo como base as não conformidades do produto com as especificações do projeto.
FMEA de sistemas: São considerados sistemas e subsistemas nas fases conceituais e de projeto. O objetivo desta análise é focalizar nos modos de falhas entre funções do sistema. São inclusas as interações entre sistemas e elementos dos sistemas.
FMEA de serviços: São analisados os serviços antes de eles atingirem o consumidor. É usado para identificar tarefas críticas ou significantes para auxiliar a elaboração de planos de controle. Ajudam a eliminar gargalos nos processos e tarefas.
Apesar de as etapas e a maneira de realização da análise serem as mesmas, existem pequenas variações entre cada tipo de análise. Um exemplo de diferença é a definição dos índices (serão descritos posteriormente) adotados na elaboração do FMEA.
Portanto, focaremos em dois tipos de FMEA por serem os mais utilizados e conhecidos: FMEA de design e FMEA de processos.
3 MECANISMOS
Os mecanismos utilizados no FMEA são relativamente simples. O método consiste basicamente em identificar e dispor todos os modos de falha em potencial em uma tabela que facilitará a sua interpretação.
Após os modos de falha estiverem sido dispostos na tabela, eles deverão ser analisados e classificados em relação à 3 aspectos: Severidade, detectabilidade e probabilidade. Pela multiplicação desses 3 índices, tem-se à disposição, os modos de falha ordenados de acordo com a sua importância. Desta maneira, obtêm-se uma tabela que auxilia na tomada de decisões de mudanças (relacionadas com o aumento de confiabilidade) no projeto.
Posteriormente, serão apresentadas explicações mais detalhadas sobre o funcionamento e elaboração de um FMEA.
5 QUANDO UTILIZAREMOS O FMEA
Inicialmente o FMEA foi desenvolvido para ser usado na fase de projetos para evitar, através de análise de falhas em potencial e propostas de ações de melhoria, que ocorram falhas nos projetos de produtos/processos. Porém ela pode ser usada ao longo do ciclo de vida do produto para detectar possíveis falhas à medida que o sistema envelhece.
É importante ressaltar que o FMEA deve ser constantemente revisado e atualizado. Durante a fase de projeto do produto, recomenda-se que se aplique ou atualize o FMEA durante os seguintes estágios:
Formulação do conceito
Projeto preliminar
Conclusão do projeto detalhado
Programas de melhoria do projeto
Possivelmente, nas fases iniciais de projeto, as informações sobre o produto estarão limitadas. Ainda assim, é possível desenvolver o FMEA respondendo a perguntas básicas como por exemplo:
Como cada parte do produto poderia falhar?
Quais mecanismos poderiam produzir estes modos de falha?
Quais seriam os efeitos se essas falhas ocorressem?
Essas falhas poderiam acarretar em algum perigo?
Como essa falha é detectada?
O que será planejado durante a fase de projeto para compensar a falha?
O FMEA também é utilizado em produtos que já estão em operação. Neste caso busca-se achar a causa raiz das falhas do sistema para propor soluções de melhoria. Assim, diferentemente do FMEA realizado na fase de projetos, não é necessário prever possíveis falhas, pois neste caso trabalha-se com falhas que já estão ocorrendo no sistema.
6 BENEFÍCIOS E INFORMAÇÕES GERADAS PELO FMEA
O FMEA traz à empresa um melhor conhecimento dos problemas nos produtos/processos. O método gera uma forma sistemática de se hierarquizar informações sobre as falhas dos produtos/processos, estabelecendo-se, portanto, um sistema de prioridades de melhorias, investimento, desenvolvimento, análises teste e validação.
A aplicação da ferramenta gera arquivos que servem como uma referência para o futuro ao nível das evoluções possíveis, da documentação de erros do passado, do desenvolvimento de técnicas avançadas de projeto e do incentivo para a necessidade constante de desenvolvimento. Desta maneira são geradas ações de melhoria no projeto do produto/processo, que devem ser devidamente monitoradas (melhoria contínua).
Devido a essa documentação de riscos e prevenção de ocorrência de falhas, o tempo e o custo de desenvolvimento diminuem. Ao mesmo tempo a confiabilidade, qualidade e segurança do produto/processo aumentam. Esse método ajuda a empresa a manter sempre o foco no cliente, garantindo sua satisfação e segurança. Assim, facilita a empresa a identificar características críticas para a qualidade.
A análise do FMEA pode ser um ponto inicial para vários outros tipos de análise, por exemplo:
Análise de sistema de segurança
Análise de planejamento de manutenção
Planejamento da produção
Análise de nível de reparos
Planejamento de testes
Análise de apoio à logística
Pode-se observar então, que o FMEA pode ser um método iterativo, pois à medida que são feitas análises adicionais, novas informações, que podem aumentar a precisão do método, surgem.
Há também o benefício de incorporar dentro da organização a atitude de prevenção de falhas, a atitude de cooperação e trabalho em equipe. Este último é importante para, entre outros aspectos, capturar o conhecimento coletivo de um time.
7 LIMITAÇÕES E ABUSOS DO FMEA
O FMEA é uma ferramenta extremamente eficiente se aplicadade maneira correta. Porém observa-se na prática muitos FMEAs que não apresentam resultados satisfatórios devido a extrapolação de seus limites pelos projetistas.
A eficácia da ferramenta está muito ligada a perícia do projetista, devido ao fato de que os modos de falha precisam ser previstos por ele. Algumas limitações do FMEA estão listadas abaixo:
O FMEA não pode ser feito até que o projeto tenha progredido a um certo ponto em que os elementos do sistema tenham sido selecionados até o nível que a análise deseja explorar
Se o FMEA for executado muito tarde, ele pode não impactar o projeto de modo eficaz e pode não garantir a confiabilidade do dispositivo
Frequentemente erros humanos e ambientes hostis são negligenciados
Os efeitos combinados de falhas coexistentes não são considerados
Se o sistema for muito complexo e a análise se estender até o nível de subsistema (ou mais detalhado), o processo pode ser extremamente tedioso e consumir muito tempo
Probabilidades de falhas podem ser difíceis de se obter. Obter, aplicar e interpretar esses dados a sistemas únicos, introduz incertezas que são difíceis de se avaliar. Além disso, a maioria dos sistemas se degradam ao decorrer do tempo, portanto possuem status múltiplos.
FMEA não analisa perigos ou problemas quando o sistema está operando devidamente
É causado um impacto inicial no cronograma do produto e de manufatura
Há uma necessidade de se compor um time com uma característica interdisciplinar elevada e posteriormente treiná-los devidamente, gerando custos.
Deve-se tomar muito cuidado também para não se negligenciar alguns itens importantes, como por exemplo:
Utilitários com Ex.: eletricidade, ar comprimido, água de arrefecimento, óleo lubrificante pressurizado, vapor, etc.
Atividades humanas de suporte - Ex.: processo de controle...
Elementos de interface
Para não tornar o FMEA extremamente tedioso, deve-se ignorar alguns itens que não auxiliam a análise de falhas, como por exemplo:
Elementos passivos em ambientes não hostis com Ex.: fios elétricos
8 COMO FAZER UM FMEA
Nesta seção será descrito como fazer um FMEA passo a passo. Serão apresentadas, primeiramente, as informações necessárias para se iniciar a elaboração do FMEA. Posteriormente, será comentada cada coluna da tabela com dicas para a sua elaboração e exemplos.
8.1 Informações necessárias
As unidades de análise do FMEA são os sistemas, subsistemas e componentes, assim divididas a fim de sistematizar todo o projeto. Deve-se definir bem a abrangência dessas unidades, não somente ao nível de discretização das funções e desempenhos individuais, mas também no nível de interações entre todas elas. Isso se faz necessário porque alterações em um subsistema podem vir a causar alterações no funcionamento de outro subsistema. O fato de dois subsistemas não estarem contato direto não significa que não possa haver interação entre eles.
Primeiramente deve-se definir o sistema a ser analisado e obter os desenhos, minutas, descrições, diagramas e listas de componentes. Defina bem o que está sendo analisado (uma área, atividade, equipamento...). Depois defina se necessita analisar o sistema inteiro ou partes dele, e quais são os alvos a serem considerados (pessoal, produto, etc.).
Faça um WBS (Work Breakdown Structure) até elementos convenientes e lógicos. Neste caso pode-se fazer tanto um WBS funcional (de acordo com as funções dos elementos do sistema) ou um de arquitetura. Pode-se considerar também a possibilidade de se fazer ambos.
Somente então deve realizar a análise dos elementos (FMEA). Criamos então um exemplo prático abaixo para mais fácil e rápida compreensão:
Geral
Anexar na tabela todas as hipóteses feitas durante a execução do FMEA e também a definição de notas usadas.
Incluir no cabeçalho da tabela a data de revisão do documento
Todos os membros do time devem ser listados no cabeçalho da tabela
Incluir nome e número do produto (parte do produto) para fácil identificação do mesmo posteriormente
Função
Cada função deve ter uma medida associada
Cada função deve ser escrita em um contexto de verbo-substantivo
Exemplo:
O sistema XYZ deve desembaçar vidros e aquecer ou esfriar a cabine até 20ºC em todas as condições de operação (de -15ºC à 45ºC)
No tempo de 4 a 6 minutos
Modo de falha em potencial
Cada função deve ser escrita em um contexto de verbo-substantivo
Cada função deve ser escrita como uma antifunção
Existem 5 tipos de modo de falhas:
Falha completa
Falha parcial
Falha intermitente
Falha devido ao excesso da função
Função indesejada
Exemplo:
O sistema ABC não aquece o veículo nem desembaça o vidro
O sistema ABC leva mais que 5 minutos para aquecer a cabine
O sistema ABC não aquece o a cabine até 20°C em temperaturas abaixo de 0°C
O sistema ABC esfria a cabine para a temperatura de 10°C
O sistema ABC liga o desembaçador traseiro
 Efeitos potenciais de falha
Os efeitos devem ser descritos do modo em que os clientes iriam descrevê-los
Efeitos devem incluir: segurança/ corpo regulador; cliente final; clientes internos - manufatura, montagem e serviços
Exemplo:
Não é possível ver além da janela da frente
O ar condicionado deixa a cabine muito fria
Não esquenta o suficiente
Leva muito tempo para aquecer
Severidade
Os índices de severidade devem corresponder, de preferência, aos índices pré-definidos na tabela 
Caso opte-se por usar um critério interno para os índices de severidade, deve-se anexar ao FMEA uma referência para as tabelas com os índices e explicações de como ela deve ser utilizada.
Exemplo:
Não é possível ver além da janela da frente com severidade 9
O ar condicionado deixa a cabine muito fria com severidade 5
Não esquenta o suficiente com severidade 5
Leva muito tempo para aquecer com severidade 4
Causas potenciais/mecanismos de falha
As falhas devem limitar-se aos interesses do projeto
A análise deve manter-se dentro do escopo definido (sistema que está sendo analisado e interface com outros sistemas)
Causas em nível de análise de componentes devem ser identificadas como características do sistema (características que podem ser controladas no processo)
Geralmente há mais de uma causa de falha para cada modo de falha
As causas devem ser identificadas para um modo de falha, e não para um efeito individual
Exemplo:
Posicionamento incorreto das saídas de ar do desembaçador
Caminho incorreto percorrido pelas mangueiras das saídas de ar (provavelmente muito próximas à s fontes de calor)
Capacidade inadequada de resfriamento para a aplicação em questão
Ocorrência
Os índices de ocorrência devem corresponder, de preferência, aos índices pré-definidos na tabela
Caso opte-se por usar um critério interno para os índices de ocorrência, deve-se anexar ao FMEA uma referência para as tabelas com os índices e explicações de como ela deve ser utilizada.
Os índices de ocorrência para o FMEA de projeto são baseados na probabilidade que uma causa pode ocorrer, de acordo com falhas passadas, performances de sistemas similares em aplicações similares.
Valores 1 de ocorrência devem ter dados que providenciam uma justificativa para tal valor. Esses dados, ou as fontes desses dados, devem ser incluídos na coluna de ações recomendadas.
Exemplo:
Posicionamento incorreto das saídas de ar do desembaçador com ocorrência 3
Caminho incorreto percorrido pelas mangueiras das saídas de ar (provavelmente muito próximas à s fontes de calor) com ocorrência 6
Capacidade inadequada de resfriamento para a aplicação em questão com ocorrência 2
 Classe
A classificação é usada para definir características potencialmente críticas ou significantes
Características críticas (sugere-se que se utilize para severidades 9 ou 10 com ocorrência igual ou maior que 2) devem possuir uma ação recomendada associada
Características significantes (sugere-se que se utilize para severidades entre 8 a 4 com ocorrênciaigual ou maior que 4) devem possuir uma ação recomendada associada
Deve-se ter um critério bem definido para cada caso de aplicação caso opte-se por não usar a classificação sugerida
Exemplo:
Não é possível ver além da janela da frente com severidade 9 - Posicionamento incorreto das saídas de ar do desembaçador com ocorrência 3 - crítica
Controle Atual do projeto
Controles preventivos são aqueles que ajudam a reduzir a probabilidade que um modo de falha ou causa de falha possa ocorrer com afetam o índice da ocorrência
Controles de detecção são aqueles que identificam problemas na fabricação dos produtos com índice de detecção associado
Se os controles preventivos e de detecção não forem listados em colunas separadas, eles devem incluir uma identificação do tipo de controle (P ou D)
Exemplo:
Especificações de engenharia (P) com controle preventivo
Dados de projetos antigos (P) com controle preventivo
Teste funcional com controle de detecção
Durabilidade geral de um produto (D) com controle de detecção
Detecção
Os índices de detecção devem corresponder, de preferência, aos índices pré-definidos na tabela XXX
Caso opte-se por usar um critério interno para os índices de detecção, deve-se anexar ao FMEA uma referência para as tabelas com os índices e explicações de como ela deve ser utilizada.
Detecção é o valor associado a cada tipo de controle de detecção
Valores de detecção igual a 1 devem eliminar o potencial para falha devido a deficiência de projeto
Exemplo:
Especificações de engenharia (P) com sem valor de detecção
Dados de projetos antigos (P) com sem valor de detecção
Teste funcional com detecção 3
Durabilidade geral de um produto (D) com detecção 5
RPN (número de prioridade de risco - risk priority number)
RPN é uma multiplicação dos índices de severidade, ocorrência e detecção.
É usado o índice mais baixo de detecção parar calcular o RPN
Não se deve usar um limite de RPN como principal elemento para a definir ações recomendadas
Exemplo:
Não é possível ver além da janela da frente com severidade 9 - Posicionamento incorreto das saídas de ar do desembaçador com ocorrência 3 com teste funcional com detecção 3 com RPN 81
Ações recomendadas
Todas características críticas ou significantes devem ter ações recomendadas associadas a elas
As ações recomendadas devem focar no projeto e devem ser dirigidas no sentido de mitigar a causa da falha ou eliminar o modo de falha
Caso as ações recomendadas não consigam mitigar ou eliminar o potencial para falhas no projeto, as ações recomendadas devem forçar as características a sofrerem uma mitigação de processo o quanto antes em um FMEA de processo.
Responsáveis e data alvo de finalização
Deve haver uma pessoa designada para assumir a responsabilidade pelo cumprimento de cada ação recomendada
Deve-se colocar um nome e não um título para assumir a responsabilidade por cada ação.
Deve-se lembrar que somente pessoas listadas como membro do time podem ser listadas pela responsabilidade de uma ação
Deve haver uma data alvo de cumprimento da ação para cada ação recomendada
Resultado das ações
O campo ação tomada deve detalhar quais ações ocorreram e quais os resultados de cada ação tomada
As ações devem ser completadas até a data alvo de finalização da ação
Ao menos que o modo de falha tenha sido eliminado, a severidade não deve mudar.
O índice de ocorrência pode ou não diminuir baseado nos resultados das ações
O índice de detecção pode ou não diminuir baseado nos resultados das ações
Caso os índices de severidade, ocorrência ou detecção não tenham melhorado, devem ser definidas novas ações recomendadas.