<<< Capa da Edição
Assunto Hot >>>

FMEA Corner O tema deste mês é Modos de Falha na FMEA
O tema do próximo mês será Efeitos

Todo mês na "Coluna FMEA", junte-se a Carl Carlson, um perito notável no campo da realização e facilitação de FMEAs, em cada edição desta coluna ele abordará um tema diferente relacionado a FMEA (baseado em seu livro FMEAs Eficazes “Effective FMEAs”) e também responderá as suas perguntas.

 

Modo de Falha [fāl-yuhr mōd, noun]
Em uma FMEA, um "modo de falha" é o modo pelo qual um item ou uma operação potencialmente falha ao atender ou entregar uma função pretendida e seus requisitos associados. Dependendo da definição de falha estabelecida pela equipe FMEA, modos de falha podem incluir a falha para executar uma função com limites definidos, desempenho inadequado ou deficiente da função, desempenho intermitente da função e/ou a realização não pretendida ou indesejada da função. Podemos ter muitos modos de falha para cada função.

O termo "modo de falha" combina duas palavras que juntas tem um único significado. O conciso dicionário Oxford English define a palavra "falha" como o ato de cessar a função ou o estado de não funcionamento. "Modo" é definido como "o caminho pelo qual alguma coisa ocorre." Combinando estas duas palavras é destacado que o modo de falha é exatamente como ele se apresenta, ou seja, (i.e. a maneira pela qual o item não atende a função pretendida ou seus requisitos).



Dica FMEA do mês
 

A identificação dos modos de falha para inclusão em uma FMEA não é uma lista acadêmica de cada modo de falha concebível (como por exemplo, uma falha provocada por um evento improvável como um meteoro atingindo o item), mas sim uma lista de potenciais modos de falha de preocupação para pelo menos um dos membros da equipe FMEA. Muitas companhias são limitadas em seu tempo, orçamento e recursos qualificados. Portanto, desde que a equipe FMEA tenha a correta adesão e seja conduzida por um facilitador habilidoso, é recomendada para limitar as entradas da FMEA para as áreas de real preocupação para um ou mais membros da equipe.

Questões Iniciais
 

Em uma FMEA, quais das seguintes opções são verdadeiras sobre o “modo de falha”? [Exibir/Ocultar Respostas]

1. Um "modo de falha" é uma razão especifica para a falha.

2. Um "modo de falha" é a maneira pela qual o item ou o sistema poderia falhar ao atender uma determinada função e seus requisitos.

3. Em uma FMEA, pode haver somente um modo de falha para cada função.

4. A descrição do modo de falha em uma FMEA deve incluir as consequências ou o impacto no usuário final.

Questões Intermediárias
 

Cenário: Em 12 de Junho de 1972, um avião da American Airlines DC-10 perdeu a sua porta de carga traseira logo depois de decolar de Detroit. Nós usaremos este incidente para praticar a identificação dos elementos de um problema FMEA.

McDonnell Douglas aprendeu com o teste de pressão da cabine que uma porta de carga indevidamente fechada poderia estourar devido a perda de pressão na cabine, potencialmente resultando no desabamento do piso do compartimento de passageiros no compartimento de carga. A solução temporária foi colocar uma aleta de ventilação na porta que fecharia com a mesma ligação que fecha a porta de carga, a qual manteria a pressão na aeronave igual a do ambiente a menos que a porta de carga estivesse fechada com segurança, e assim alertando o piloto do problema. Entretanto, um pouco de força excessiva de um bagageiro poderia fazer a aleta de ventilação fechar mesmo se a porta não estivesse completamente fechada.

O DC-10 com a aleta de ventilação da porta do compartimento de carga foi colocada de volta em serviço. Em uma breve parada o Vôo 96 deixou Detroit, um manipulador de carga teve problemas para fechar a porta do compartimento de carga traseiro, mas ela foi fechada com um pouco de força extra. Uma vez que o sinalizador de porta travada indicava “fechado,” e a luz de advertência no cockpit não mostrou nenhum problema. Entretanto, a força do manipulador de carga usado para fechar a porta gerou um atrito metálico na parte de dentro da porta, impedindo-a de fechar corretamente. A pressão do ar durante a subida gerou muito força o que dobrou o pino de trava da porta. Isto arrancou os pinos, liberando a porta. A cabine próxima da porta caiu e ficou presa aos cabos de controle na cauda. O resto é história trágica.

A sequência de prováveis falhas da porta de carga do DC-10 foram:

1. O manipulador de cargas da Aeronave usou força extra para fechar a porta traseira, houve uma dobra dos pinos da porta. A porta não fechou seguramente.
2. A aleta de ventilação não alterou o alarme eletrônico, e o piloto não foi avisado de que a porta de carga traseira não fechou com segurança.
3. A pressão de ar fora do lado de fora da porta de carga cai durante a subida, até que a pressão do lado de dentro da porta causasse o cisalhamento do pino da trava de segurança. A porta de carga estoura.
4. A Alta pressão do ar dentro da cabine arrebenta a porta, resultando em linhas hidráulicas e cabos não funcionais.

Nós usaremos o pino de trava da porta do DC como subsistema da porta do compartimento de carga traseiro para um exemplo prático de identificação das funções, falhas, modos de falhas, efeitos, causas e controles, baseados no histórico de falha do pino de trava da porta do compartimento de carga traseiro. Este mês nós focaremos em uma possível função e modo de falha do pino de trava da porta do compartimento de carga traseira do DC-10. Nós continuaremos este exercício nos próximos meses onde iremos nos concentrar na identificação adequada dos efeitos de falha, causas e controles.

Problema: Use para a falha “cisalhamento” e use o pino da trava da porta do compartimento de carga traseiro do DC-10, como subsistema do travamento da porta do compartimento de carga como exemplo de identificação de uma possível função do pino de trava da porta do compartimento traseiro e um possível modo de falha para a função identificada. [Exibir/Ocultar Resposta]

O que eu sempre quis saber sobre FMEAs

  

O leitor da HotWire Tom Crenna, da Arthrex, Inc., enviou a seguinte questão para o Carl Carlson:

Oi Carl,
Nós temos um Sistema de dispositivo medico eletro-cirúrgicos que consiste no seguinte:

1. Devo considerar o usuário e paciente como parte deste sistema? [Veja a resposta]
2. Como poderíamos realizar uma Aplicação ou Sistemática de FMEA sobre eles? [Veja a resposta]
3. É uma FMEA de Aplicação ou de Sistema a mesma coisa? [Veja a resposta]

Carl: Oi Tom. Estas são excelentes perguntas.

A Resposta para a Primeira questão: Devo considerar o usuário e paciente como parte deste sistema?

Deixe me começar minha resposta com a definição do escopo de um “Sistema FMEA”:

Sistema FMEA é o mais alto nível de análise de um sistema inteiro, feito de vários subsistemas. O foco está sobre as deficiências relacionadas ao sistema, incluindo segurança do sistema, integração do sistema, interfaces ou interações entre subsistemas ou com outros sistemas, interações com o ambiente ao seu redor, interações humanas, serviços e outras questões que poderiam causar o não funcionamento de todo o sistema como esperado. Na FMEA do Sistema, o foco está sobre as funções e relações que são únicas para o sistema como um todo (p.e. não existem nos níveis inferiores). O FMEA no nível de Sistema inclui modos de falha associados com as interfaces e interações além de considerar as falhas de ponto único (onde a falha de um simples componente pode resultar em uma falha completa do sistema). Alguns praticantes isolam interações humanas e serviços dentro de suas respectivas FMEAs.

Como você pode ver nesta descrição, o escopo não é gravado em uma pedra. Cabe a equipe FMEA (e o apoio gerencial) determinar o escopo exato de FMEAs individuais. Para uma situação como a descrita por você, há duas abordagens que os praticantes usam. Uma abordagem é fazer duas FMEAs diferentes: um FMEA de Sistema que inclui apenas os dispositivos próprios do sistema e não as interações/interfaces entre o sistema e os usuários e pacientes. A segunda abordagem é fazer um FMEA de Sistema mais abrangente, o qual inclui dentro do escopo as interações/interfaces com os usuários e pacientes além dos dispositivos do sistema. Padrões internacionais ou políticas da companhia podem ditar qual a abordagem você deverá utilizar, então é importante se familiarizar com normas e políticas apropriadas. Independentemente de qual abordagem você usa, garanta que o escopo esteja visível através do uso adequado de um Diagrama de Blocos FMEA. Este irá mostrar claramente o escopo do seu FMEA, incluindo interfaces com humanos.

A Resposta para a Segunda questão: Como poderíamos realizar uma Aplicação ou Sistemática de FMEA sobre eles?

Uma resposta completa para esta questão vai além do escopo deste forúm. Em FMEAs Eficazes, Eu dedico três capítulos inteiros para a preparação, procedimento e implementação de todos diferentes tipos de FMEAs, incluindo FMEA de Sistema. Dito isto, deixe me fornecer algumas dicas para você começar.

Vamos supor que você sabe como preparar e conduzir uma FMEA e que saber o que é diferente em um FMEA de Sistema (incluindo as interações com usuários e pacientes). Uma das primeiras considerações é incluir as interfaces com humanos na hierarquia do sistema (como você tem feito), ou incluir as interfaces humanas como funções de interfaces na lista de funções primárias no nível do sistema. Eu normalmente uso o último, mas isto pode ser feito do outro modo. A coisa mais importante é incluir interações do sistema com humanos em qualquer lugar, para que você não se perca em suas FMEAs.

Se você incluir a interface entre usuário(s)/paciente(s) e o sistema ESU bipolar na hierarquia do sistema, então ele deve descrevê-lo na hierarquia do sistema como “interface usuário-sistema” e “interface paciente-sistema” em vez de meramente “Usuário(s)” e “Paciente(s)”. Se você incluir as interfaces do usuário/paciente com o sistema como funções da interface, garanta que elas estão apropriadamente descritas como descoberto na "Coluna FMEA" da HotWire de Abril, incluindo o padrão de desempenho para cada função. Também é importante para que se faça Diagrama de Blocos de FMEA, e mostrar claramente o escopo do seu FMEA, e exibir os quatro tipo de interfaces (conexões físicas, troca de material, transferência de energia e/ou troca de dados).

Um outro ponto é incluir em seu FMEA de Sistema as interfaces entre os vários subsistemas, como os que podem gerar mais de 50% dos modos de falhas. Você terá que revisar suas escalas de ranqueamento do risco para garantir que elas estejam adequadas ao FMEA de Sistemas, FMEA de Aplicações (se você fizê-las separadamente) e FMEAS de Projetos (tipicamente feitas a um subsistema ou nível de componente).

A Resposta para a Terceira Questão: É uma FMEA de Aplicação ou de Sistema a mesma coisa?

Eu acho que já abordamos este assunto. Muitas companhias de dispositivos Médicos separam as FMEAS de Sistemas (escopo: o sistema do dispositivo) e FMEA de Aplicação (ou fatores humanos) (escopo: interfaces entre dispositivos do sistema e humanos). Como dito acima, você pode fazer isto separadamente, ou combiná-los dentro de um ou mais FMEAs de Sistemas compreensíveis. A chave é mostrar claramente o escopo de sua FMEA, e incluir todas as interfaces subsistemas-para-subsistemas, assim como as interfaces entre usuário(s)/paciente(s) e o dispositivo do sistema.


   

Sobre o autor

FMEA Corner

Carl S. Carlson é um consultor e instrutor nas áreas de FMEA, planejamento de programa de confiabilidade e outras disciplinas de engenharia de confiabilidade. Ele tem 30 anos de experiência em cargos de testes de confiabilidade, engenharia e gestão, e está atualmente apoiando os clientes da ReliaSoft Corporation, com treinamentos e consultorias de confiabilidade FMEA. Antes da ReliaSoft, trabalhou na General Motors, e mais recentemente gerencia sênior do Grupo Avançado de Confiabilidade. Suas responsabilidades incluíam FMEAs para as operações norte-americanas, desenvolvimento e implementação de métodos avançados de confiabilidade e gerenciamento de equipes de engenheiros de confiabilidade. Anteriormente a General Motors, trabalhou como Engenheiro de Pesquisa e Desenvolvimento para Littion Systems, na Divisão de Navegação de Inércia. Sr. Carlson co-presidiu a equipe cruzada da indústria que desenvolveu o padrão FMEA comercial (SAE J1739, versão 2002), participou do desenvolvimento da SAE JA Guia de Implementação 1000/1 do Programa Padrão de Confiabilidade, servindo por cinco anos como Vice-Presidente para a Divisão de Confiabilidade da SAE G-11 e foi membro do Conselho Consultivo do Simpósio de Confiabilidade e Manutenção (SCEM) por quatro anos. Ele possui um B.S. em Engenharia Mecânica pela Universidade de Michigan e completou em seguida seu segundo curso de Engenharia de Confiabilidade pela Universidade de Mestres em Maryland através do programa de Engenharia de Confiabilidade. Ele é um membro sênior da ASQ e um Engenheiro Certificado de Confiabilidade.

FMEA Corner

O material para as dicas, problemas e soluções FMEA são extraídos do livro FMEAs Eficazes, publicado por John Wiley & Sons, © 2012. Informações sobre o livro FMEAs Eficazes, junto com anúncios, links e listas de verificação úteis de FMEA que podem ser encontradas em www.effectivefmeas.com.

 
ReliaSoft