mÓdulo 2 práticas do dfmea (planejamento do … · diagrama de blocos. subconjuntos componentes...

49
MÓDULO 2 Práticas do DFMEA (Planejamento do Projeto), aplicando-as em situações do dia a dia.

Upload: vutruc

Post on 06-Oct-2018

219 views

Category:

Documents


0 download

TRANSCRIPT

MÓDULO 2

Práticas do DFMEA (Planejamento do Projeto), aplicando-as em situações do

dia a dia.

“SE ALGUMA COISA PODE DAR ERRADO, DARÁ, NO PIOR MOMENTO.”

� A primeira função do engenheiro de projeto é fazer as coisas difíceis, para fabricação e utilização, bem como impossíveis para a manutenção.

� Em qualquer projeto, o componente de vida mais curta, seráinstalado num lugar de acesso mais complicado.

� Qualquer projeto deve conter pelo menos 1 peça obsoleta, 2 impossíveis de encontrar e 3 ainda sendo testadas.

� O engenheiro de projetos mudará o desenho original na última hora, para incluir novos defeitos.

� O engenheiro de projetos mudará o desenho original na última hora, para incluir uma nova manutenção (famoso fator K).

� O problema no produto sempre irá ocorrer quando o cliente estiver usando o produto e nunca quando ele estiver em teste.

“Lei de Murph”

2

Redução do risco de falhas no projeto –Objetivos

� Ajudar na avaliação do objetivo do projeto, incluindo requisitosfuncionais e projetos alternativos.

� Avaliar o início do projeto para a manufatura, montagem,assistência técnica e requisitos de reciclagem.

� Aumentar a probabilidade de que os modos de falhas potenciais,e seus efeitos no sistema, tenham sido considerados noprocesso de desenvolvimento e de projeto.

� Fornecer informações adicionais para auxiliar no planejamento,através de um eficiente e completo projeto, desenvolvimento eensaios/análises de validação.

� Fornecer um formato de assuntos abertos, para recomendaçõese rastreamento de ações de redução de riscos.

� Fornecer referência futura, para ajudar a conciliar aspreocupações de campo, avaliações de alterações de projeto edesenvolvimento de projetos avançados.

Aplicações do FMEA de Projeto (DFMEA)

� O DFMEA deve:

�Ser iniciado antes da finalização da concepção doprojeto;

�Ser atualizado continuamente, sempre que houverqualquer mudança, ou informação adicional;

�Estar completo antes do projeto de produção serentregue;

�Ser uma fonte de lições aprendidas, para interaçõesde futuros projetos.

� A análise é realizada, subdividindo-se o produto em níveisde complexidade, como: Sistemas completos, Sub-sistemas, Sub-conjuntos e Componentes.

� A análise das partes menores é feita, utilizando-se oDiagrama de Blocos.

SubconjuntosComponentes

Sistema

Subsistemas

Diagrama de blocos - Exemplo

M: significa conexão mecânica

E: significa conexão elétricaMotor elétrico

Palheta

Mecanismo de movimentação

Sistema de acionamento

do motor elétrico

M

M

E

Pára-brisa

Carroceria

M

M

M

M

Limite de análise do FMEA

� Ao se iniciar um DFMEA, a equipe designada para o trabalho deve, na forma deconsenso dessa equipe (vide figura):

�Estabelecer o limite de análise (onde começa e onde acaba)

�Elaborar o Diagrama de Blocos

�Definir o escopo a ser tratado

Limite de Análisedo FMEA

Definição do Escopo a ser

tratado

Consenso daEquipe

Diagrama deBlocos

Robustez

� Robustez é a habilidade de um produto atender as expectativas dosclientes, considerando os fatores de ruído.

� Problemas de falta de robustez são causados por fatores de ruído.

� Fatores de ruído: são fatores não controlados, que interferem noproduto.

� As relações de robustez foram acrescentadas ao processo de FMEA,para reduzir significativamente campanhas publicitárias (recall),melhorar a imagem da empresa, diminuir os pedidos por garantia eaumentar a satisfação do cliente.

� Essas relações provêm, principalmente, do Diagrama P, que identificaos fatores de ruído. Tais fatores precisam ser tratados, anteriormente,para tornar o projeto insensível aos ruídos. Essa é a essência darobustez.

� É de responsabilidade do engenheiro garantir que as relações derobustez sejam registradas, na documentação da engenharia.

Relações de robustez

� A previsão de erros e a melhoria da robustez são esforços distintos, porémcomplementares, para se evitar os modos de falha. Cada um apresenta seu própriofoco e eficiência.

� O fluxograma do próximo slide, ilustra o fluxo de informações, que ocorre quando umaequipe executa um FMEA.

�As flechas que descem, representam o fluxo principal;

�As que sobem, representam as lições aprendidas e o feedback;

�A flecha que apresenta dois sentidos, representa a interface entre um FMEA e umREDPEPR (Robustness Engineering Design Product Enhancement Process -Projeto de Engenharia de Robustez e Processo de Melhoria do Produto).

� O Histórico da Qualidade sempre é uma entrada importante, pois suas informaçõesprecisam ser levadas em consideração, para prevenir re-ocorrência de erros.

Relações de robustez

Prevenindo os modos de falha Histórico da qualidade

Diagramade blocos

Matriz deinterface

Erro Problema de robustez

FMEACom campanha e

histórico de qualidade

REDPEPRDiagrama P

RCLRDM

Plano de verificação do projeto (DVP)

Diagrama de blocos

� Um produto pode ser descrito e analisado, em diferentes níveis de complexidade,sendo que cada nível pode ser descrito, fisicamente ou funcionalmente (os níveis decomplexidade do produto podem ser: produto ou sistema completo, sub-sistemas, sub-conjuntos, peças ou componentes).

� Sua construção objetiva dividir um sistema ou produto complexo, em partes menoresque, por sua vez, partes que podem ser melhor administradas.

� A ferramenta oferece a oportunidade de analisarmos o relacionamento entre oscomponentes principais de um sistema ou produto, indicando, também, os limites deanálise para os trabalhos de DFMEA.

� No seu desenvolvimento, deve-se:

� Identificar os principais elementos do sistema, e desenhá-los em caixas;

�Organizar as caixas, e conectá-las através de setas;

�Desenhar os limites de análise, ao redor dos componentes do sistema, que devemser considerados;

� Identificar interferências externas, de entrada e de saída, que cruzam os limites deanálise.

Diagrama de blocos - Exemplo

Carga

Ponta

Suporte

Mola

Tampa

Carga Tampa

Mola Ponta

Suporte

Ambiente

Diagrama de blocos - Exemplo

Manter o pára-brisa limpo ou sem

água

Injetar água no pára-brisa, com

pressão adequada, para retirar partículas de

sujeira

Retirar partículas de sujeira e a

água do pára-brisa

Retirar as partículas de sujeira e água

Movimentar a haste da palheta

Armazenar água

Bombear a água na pressão adequada

Direcionar o jato de água

Ação recomendada

Dados construtivos:Dimensões Material

Rotação do motor

DFMEA

Diagrama – Outro exemplo

Ambiente:•

Temperatura ambiente

• Umidade• Carga da estrada (vibração)• Off road (destroços/pedra)•

Sal / lama / água da estrada

Escapamento

Montagem do catalisador

Suportes Concha / Cone

Substrato revestido

Vedações

Fundo de corpo

� Fluídos do veículo•A/C condensado•Resfriador do motor•Resfriador de transmissão

•Óleo do reservatório de óleo

Sistema de enquadre e montagem

Subsistema de componentes de controle acústico

Sistema de suporte aos tubos de escapamento

Sistemade motor

Cones Internose isolamento

Sensores de escape Placas acústicas

Subsistema de controle de emissão do motor

Humano

Subsistema de escudos e encaixes

Matriz de Interface (sugestiva)

� Ilustra relações entre os sub-sistemas, montagens, sub-montagens e componentes,dentro do objeto, bem como interfaces com os sistemas e ambientes vizinhos.

� Ela identifica detalhes, como: tipos de interfaces, força e importância das interfaces e oefeito potencial da interface.

� É uma ferramenta de robustez recomendada como entrada para o DFMEA, poisidentifica funções primárias e funções de interface, para análise da função do sistemae/ou efeitos de sistemas, ambientes ou pessoas, para poder enxergar causas potenciaise falhas de mecanismos.

� Fornece, também, entrada para o Diagrama P (entrada e saída de fatores de ruído),como veremos.

� O não atendimento das interações apontadas por essa Matriz, pode levar a problemasde garantia e recall.

� Nessa Matriz, toda interface, com impacto positivo ou negativo, deve ser verificada e,em seguida, os impactos negativos são analisados para ações corretivas e/oupreventivas. Quando completada ou revisada, anexe a Matriz de Interface ao FMEA.

Matriz de Interface - Exemplo

22Ambiente

2220Ponta

22Mola

222Tampa

022Carga

22Suporte

AmbientePontaMolaTampaCargaSuporte

Matriz de interface

MI

EP

Interfaces•P: Toque físico•E: Transferência de energia•I: Troca de informações •M: Troca de materiais

Valores indicados são os tipos de interfaces:

+2: interação énecessária para função+1: interação é benéfica, mas não absolutamente necessária para a função0: interação não afeta a funcionalidade-1: interação causa efeitos negativos, mas não atrapalha a funcionalidade-2: interação deve ser prevenida para atingir a funcionalidade

Diagrama P - Parâmetros (sugestivo)

� Ferramenta estruturada, recomendada para identificar entradas (sinais) e saídas(funções intencionais), para o assunto investigado. Descreve, pois, fatores de ruído,fatores de controle, função ideal e estados de erro.

� Uma vez que as entradas e saídas forem identificadas, para uma função específica, osestados de erro são conhecidos.

� Fatores de controle: são os meios para tornar mais robusta a função do item.

� Estado de erro: pode ser classificado em duas categorias:

�Desvio da função intencional (é igual aos modos de falha potenciais, no FMEA),que pode ser:

• Sem função;

• Função parcial (incluindo função degradada ao longo do tempo);

• Função intermitente;

• Função excessiva.

�Saída não intencional do sistema (ex: vibrações do motor).

� Resumindo, ele auxilia na identificação de: causas potenciais de falha, modos defalha, efeitos potenciais das falhas, controles atuais, ações recomendadas.

Diagrama P - Exemplo

Entradas

Sistema/Sub-sistema/Componente

• Listar todas as funções, primárias e secundárias.

• Numerar as funções, tal que as entradas, respostas e estados de erros, possam ser relacionados à função.

• Tomar, como referência, o Diagrama de Blocos, pararelações funcionais.

• Entre cada interface, há um mínimo da função.

• Listar os sinais exigidos, paracada função (ex.: voltagem, torque). São hipóteses funcionaisque o item irá responder.

• Expressar em termos técnicos de engenharia (ex: torque, RPM, Volts, hz etc).

• O sinal precisa ser mensurável.

• Indicar qual sinal de entrada éexigido, para cada função.

Fatores de ruído

Listar todos os fatores de ruído (não controlados):

- Variação peça a peça;

- Mudanças ao longo do tempo/milhagem (ex.: desgaste);

- Uso pelo cliente;

- Ambiente externo (ex.: tipo de estrada, clima);

- Interação de sistemas, com componentes adjacentes.

Fatores de controle

• Listar todos os fatores de projeto (que podem ser controlados), que afetam cada item de função(seleção de materiais, número de marchas, etc).

• Fonte: SDS (Especificações do Projeto do Sistema).

�Listar as respostas ideais, baseadas nos sinais de entrada fornecidos. •Expressar a entrada emtermos de engenharia). •O sinal deve ser mensurável.•Indicar (numeração) qualsinal de entrada éexigido,para cada caso.

�Listar respostas não-ideais, baseadas no sinal de entrada.

�Considerar: Falha total, falhaparcial ou por degradação, falhas intermitentes, falhasnão intencionais (indicador de erro).

Respostas ideais

EstadosEstados de de erroerro

Diagrama P – Exemplo

Check list de robustez (RCL)

� É uma análise detalhada do impacto causado pelos fatores de ruído, às funçõesideais e aos estados de erro;

� Gera estratégias de gestão de fatores de ruído;

� Une o DFMEA e os fatores de ruído no Plano de Verificação do Projeto (DVP).

Estados de erro

Fatoresde ruído

Testes de avaliação

Modo de falha, para testar a rastreabilidade

Gerenciamento

estratégico dos

fatores de Ruído

FMEA

DVPRCL

Fatoresde ruído

SistemaFator sinalizador

Fatores de controle

Estados de erro /Modos de falha

Função ideal

Entradas Saídas

Diagrama P Estados de erro

Fatoresde ruído

Testes de avaliação

Modo de falha, para testar a rastreabilidade

Gerenciamento

estratégico dos

fatores de Ruído

FMEA

DVPRCL

Fatoresde ruído

SistemaFator sinalizador

Fatores de controle

Estados de erro /Modos de falha

Função ideal

Entradas Saídas

Diagrama P

Plano de Verificação do Projeto (DVP)

� Matriz de Demonstração da Robustez (RDM): Abordagem de dados induzidos, emque os testes dos fatores de ruído e os testes métricos são medidos / quantificados,de modo a atender a robustez desejada.

Fatores de ruído são incorporados nos

procedimentos de testes

Testes representam o perfil de uso

DVP

Duração dos testes representa a meta de

confiabilidade

Testes descrevem o modo de falha

DFMEA, passo a passo

FUNÇÃO

NPR = SEV x OCOR x DET

MODO DE FALHA

CAUSAS (OCO) EFEITOS (SEV)

CONTROLE PREVENTIVO

CONTROLE DETECTIVO

AÇÕES RECOMENDADASPARA

REDUÇÃO DO NPR

Formulário do DFMEA

Pode-se adicionar colunas (exemplo: separar item, função e requisitos). Pode variar de produto para produto, empresa e complexidade do projeto (a empresa estabelece o formulário mais adequado).

FMEA Nr. ___________________

Número da peça: _____________________ Responsável pelo projeto: ____________________________________ Página __________ de ____________

Descrição: ______________________ Data FMEA (original): ________________________________________ Emitente _____________________

Sistema/Subsistema/Seção: ________ Data FMEA (revisâo): ________________________________________ Data emissão ___________________

Participantes do grupo: __________________________________________________________

Ações tomadas

FunçãoData

efetiva

Responsabilidade pela ação

recomendada & Data da conclusão

Modo de Falha Potencial e Análise de Efeitos (FMEA de Projeto)

Plano de Verificação de

Detecção

Detec

N P R

Ações Preventivas

Recomendadas

ItemCausa(s) Potencial

Mecanismo(s) de Falha

ocor r

Plano de Verificação de

Prevenção

Modo de falha Potencial

Efeito Potencial da Falha

severid

c l ass

Resultado das ações

S e v

O c o r

D e t

N

P

R

Definição de “Item” no DFMEA

� O item expressa as peças ou interfaces, identificadas no diagrama P e nos blocos,esquemas e desenhos, que foram conduzidos pela equipe.

� A função, expressa “a atividade ou uso, para qual o item se destina”.

� A função do item ou interface, deve estar no formato: Verbo no infinitivo +Substantivo.

� Recomendação: se o item ou interface tiver mais que uma função, com diferentesmodos de falhas potenciais, essas funções devem ser listadas separadamente.

� Incluir especificações de desempenho, que são desejadas, e seus respectivos valorespara cada função.

� Definição de especificações:

�Incluir condições de operações especiais, sempre mensuráveis.

�Recomendação: se a função tiver mais que um requisito, com diferentes modospotenciais de falhas, cada um dos requisitos e funções deve ser listadoseparadamente.

“Item, Função, Requisito” - Exemplo

Deve liberar a resistência ao torque, especificada no eixo.

Permitir a transferência da força do pedal do freio, para o eixo.

Rotor do freio

Veículo para, em asfalto seco, dentro da distância especificada, com g’s de força.

Permite o desimpedimento do movimento do veículo, quando o sistema não for solicitado.

Parar o veículo, quando solicitado, considerando as diferentes condições ambientais, tais como: molhado, seco, etc.

Sistema de freio a disco

RequisitoFunçãoItem

“Modo de Falha” no DFMEA

� É a forma pela qual o componente, sub-sistema ou sistema, deixa de atender osrequisitos de projeto e/ou as expectativas do cliente, da coluna “Item”.

� Considera todos os tipos de falhas possíveis (inclusive aqueles que acontecem, devidoa condições ambientais ou de uso).

� Recorre a FMEA’s anteriores, relatórios de problemas e de qualidade, garantia,durabilidade, voz do cliente e falhas em itens similares.

� Para facilitar na identificação, há dois tipos de abordagens:

Abordagem Funcional�Como é a função, não realizada?�Como é a função, realizada apenas parcialmente?�Como é a função, realizada apenas de vez em quando?�Como é a função, realizada de forma degrada?�Como é a função, realizada de forma exagerada?

Abordagem Física�Derivada da abordagem funcional.�Deve ser considerada, quando do preenchimento do DFMEA.�Os modos de falhas são expressos em termos físicos.�Exemplos: achatado, amassado, trincado, entupido.

Relação das abordagens, funcional e física

causa efeitoabordagem

físicaabordagem funcional

função

modo de falha

�A causa está ligada à abordagem física, a função à abordagem funcional.

�O modo de falha leva em conta as duas abordagens (física e funcional).

�O modo de falha influencia no efeito.

“Modo potencial de falha” - ExemploItem Função Requisito Modo de Falha

Sistema de freio a disco

Parar o veículo, quando solicitado (considerando as condições ambientais, tais como: molhado, seco etc).

Veículo para, em asfalto seco, dentro da distância especificada com g´s de força.

O veículo não para.

O veículo para, excedendo a distância especificada.O veículo para, com mais de X g´s de força.

Permite o desimpedimento do movimento do veículo, quando o sistema não for solicitado.

Ativado, quando não houver solicitação.O movimento do veículo éparcialmente impedido.

Ativado, quando não solicitado.O veículo não pode se mover.

Rotor do freio Permitir a transferência da força, do pedal do freio para o eixo.

Deve liberar a resistência ao torque, especificada no eixo.

Resistência ao torque liberada, de forma insuficiente.

Análise de falhas - Exemplo

Não manter o pára-brisa limpo, na área de visão do motorista

Não injetar água no pára-brisa, no ponto certo, para permitir

uma retirada completa da sujeira

Não retirar partículas de sujeira e a água

do pára-brisa

Não retirar as partículas de sujeira e água

Não movimentar a haste da palheta

Não bombear a, água, na pressão adequada

Não armazenar água

Não direcionar o jato d’agua

Não sustentar a palheta e transmitir o movimento do motor à palheta

Dimensões incorretas

Material inadequado

Rotação insuficiente

“Efeito de Falha” no DFMEA

� Descrição das conseqüências da falha, em termos derequisitos de uso, função ou situação do produto.

� Um único modo de falha pode originar vários efeitos.

� Considera:

�Insatisfações dos clientes (interno e externo)�Performance

�Influências sobre outros sistemas

�Segurança

�Normas governamentais

� Exemplos: Ruído, Vibração, Cheiro, Operaçãoincorreta, Aparência degradada, Operaçãointermitente, Inoperância, Custo elevado.

“Efeito de Falha” - ExemploItem Modo de falha Efeito

Sistema de freio a disco

O veículo não para. Controle do veículo danificado; não atendimento ao requisito legal.

O veículo para, além da distância especificada.

Controle do veículo danificado; não atendimento ao requisito legal.

O veículo para, com mais que X g´s de força.

Não atendimento ao requisito legal.

Ativado, sem ser solicitado; o movimento do veículo fica parcialmente impedido.

Redução da vida do pedal; diminuição do controle do veículo.

Ativado, sem ser solicitado; o veículo não pode se mover.

O cliente é incapaz de dirigir o veículo.

“Severidade” no DFMEA

� Estimativa da gravidade dos efeitos de falha, associados a (exemplos): Insatisfação docliente, Custo para a empresa, Performance da empresa, Imagem da empresa, Riscosde segurança pessoal e do usuário, Desobediência às regulamentaçõesgovernamentais.

� Existe um índice de severidade, que somente se aplica aos efeitos.

� Esse índice deve ser estimado numa escala que vai de 1 (um) a 10 (dez).

� Não é recomendado que se modifique os critérios dos valores 9 e 10. Os modos defalhas com um valor de severidade 1, não deveriam ser analisados.

10 e 9

1

“Índice de Severidade” (S)

Efeito Critério: Severidade do efeito - cliente Classif.

Falha em atender aos requisitos de

segurança e legais

Modo de falha potencial afeta a segurança na operação do veículo e/ou envolve não-conformidade com a legislação governamental, sem aviso prévio.

10

Modo de falha potencial afeta a segurança na operação do veículo e/ou envolve não-conformidade com a legislação governamental, com aviso prévio.

9

Perda ou degradação da função primária Perda da função primária (veículo inoperante, mas não afeta a operação segura do

veículo)8

Degradação da função primária (veículo operante, mas com nível de desempenho reduzido).

7

Perda ou degradação da função secundária

Perda da função secundária (veículo operante, mas funções de conforto / conveniência inoperantes)

6

Degradação da função secundária (veículo operante, mas funções de conforto / conveniência com níveis reduzidos de desempenho)

5

Aborrecimento (prejuízo)

Acabamento ou barulho, veículo operante, item não conforme é observado pela maioria dos clientes (mais de 75%).

4

Acabamento ou barulho, veículo operante, item não conforme é observado por 50% dos clientes.

3

Acabamento ou barulho, veículo operante, item não conforme é observado por determinados clientes (menos de 25%).

2

Nenhum Sem efeito notado 1

“Classificação” no DFMEA

� Esta coluna pode ser usada para delinear, prioritariamente, os modos de falhas e ascausas associadas.

� Como resultado das análises, a equipe pode usar esta informação, para identificar ascaracterísticas especiais.

� Os requisitos específicos do cliente podem identificar os símbolos de característicasespeciais, do produto ou do processo e de seu uso.

� Uma característica designada no registro do projeto como especial, sem umaassociação com um modo de falha do projeto, é uma indicação de uma fraqueza noprocesso do projeto.

“Causa / Mecanismo de falha” no DFMEA

� É a razão pela qual ocorrerá o modo de falha, ou seja, é a indicação do ponto fraco doprojeto.

� Um tipo de falha pode ter várias causas distintas.

� As causas devem ser descritas da maneira mais completa e específica possível,visando orientar as ações preventivas para elas.

� Para um sistema, o mecanismo de falha é o processo de propagação do erro docomponente, que conduz à falha do sistema.

� Um produto ou processo pode ter vários modos de falha, que são relacionados uns aosoutros, devido a um mecanismo de falha comum entre estes.

� Deve-se garantir que os efeitos do processo sejam considerados como parte doprocesso de DFMEA.

� Causas são as circunstâncias que induzem ou ativam um mecanismo de falha.

Exemplos de “causas”Modo de falha Mecanismo Causa

O veículo não para.Não há transferência de força, do pedal para as

pastilhas.

Quebra da ligação mecânica do freio, devido à proteção corrosiva inadequada.

Cilindro principal de vácuo fechado, devido ao projeto do selo.

Perda do fluído hidráulico através da linha, devido à especificação de torque errado do conector.

Perda do fluído hidráulico, devido à linha estar obstruída, comprimida, especificação inadequada do material do tubo.

O veículo para, com excesso de Y metros.

Transferência reduzida de força, do pedal para

as pastilhas.

As juntas mecânicas de ligação estão duras, devido à especificação inadequada do lubrificante.

As juntas mecânicas de ligação estão corroídas, devido à proteção corrosiva inadequada.

Perda parcial do fluído hidráulico, devido â linha obstruída, material especificado do tubo inadequada.

O veículo para, com mais que X g´s de força.

Transferência rápida / excessiva de força, do

pedal para as pastilhas.Pressão acumulada no cilindro principal, devido ao projeto do selo.

Ativado, sem solicitação. O movimento do veículo

é impedido.

As pastilhas não se soltam.

Corrosão ou depósito nos trilhos ou pastilhas, devido ao acabamento superficial, que não fornece adequada auto-limpeza e proteção contra

corrosão.

Ativado, sem solicitação. O veículo não pode se

mover.

A pressão hidráulica não é liberada.

O cilindro de vácuo principal fechado, devido ao projeto do selo.

“Ocorrência” no DFMEA

� Exemplos de causas de falha:

�Especificação incorreta do material, Solicitação abusiva, Instruções inadequadasde manutenção, Dimensões inadequadas, Vida do projeto assumida de formainadequada, Dimensionamentos incorretos, Canais insuficientes.

� Ocorrência é a estimativa de que uma causa / mecanismo específico, venha a ocorrer,resultando no modo de falha dentro da vida do projeto, levando em consideração:

�Se o componente é novo, a experiência histórica, se há modificações no ambiente,se algum plano de controle preventivo foi usado, se a aplicação do componente foialterada.

� A classificação da ocorrência deve variar numa escala de 1 a 10.

10

1

“Índice de Ocorrência” (O) no DFMEA

Probabilidade de falha

Critério: Ocorrência da causa – DFMEA (Vida do projeto/ confiabilidade do item / veículo

Critério: Ocorrência da causa – DFMEA

(incidentes por itens/ veículos)

Classificação

Muito alta Nova tecnologia / novo projeto, sem histórico≥ 100 em 1000

≥ 1 em 1010

Alta

A falha é inevitável com o novo projeto, aplicação ou modificação, nas condições de operação, ciclo obrigatório.

50 em 10001 em 20

9

A falha é provável com o novo projeto, aplicação ou modificação, nas condições de operação, ciclo obrigatório.

20 em 10001 em 50

8

A falha é incerta com o novo projeto, aplicação ou modificação, nas condições de operação, ciclo obrigatório.

10 em 10001 em 100

7

Moderada

Falhas freqüentes associadas com projetos similares, ou em simulação e ensaio do projeto.

2 em 10001 em 500

6

Falhas ocasionais associadas com projetos similares, ou em simulação e ensaio do projeto.

0,5 em 10001 em 2.000

5

Falhas isoladas associadas com projetos similares, ou em simulação e ensaio do projeto.

0,1 em 10001 em 10.000

4

Baixa

Somente falhas isoladas, associadas com projetos similares ou em simulação e ensaio do projeto.

0,01 em 10001 em 100.000

3

Nenhuma falha observada, associada com projetos similares ou em simulação e ensaio do projeto.

≤ 0,001 em 10001 em 1.000.000

2

Muita baixa Falha é eliminada através de controle preventivo.Falha é eliminada

através de controle preventivo

1

“Controle Atual do Projeto” no DFMEA

� São formas de controle previstas, que devem atuar, sobre omodo de falha e sobre as causas apontadas.

� Asseguram a adequação do projeto, aos modos de falha ouaos mecanismos em consideração.

� Há dois tipos de controle de projeto, a considerar:

�Preventivo: elimina (previne) a causa do mecanismo dafalha ou do modo de falha vir a ocorrer, ou reduz a taxa deocorrência.

�Detectivo: identifica (detecta) a existência de uma causa, omecanismo resultante da falha ou o modo de falha, atravésde métodos analíticos ou físicos, antes do item entrar paraa produção.

�A abordagem preferencial é o controle preventivo.

Exemplos de “controle de projeto”

Controles detectivos:

� Revisões de projetos

� Ensaios com protótipos

� Ensaios de validação

� Estudos de simulação, para validação do projeto

� DOE (delineamento de experimentos), incluindo ensaios de confiabilidade

� Dispositivos usando peças similares

Controles preventivos:�Estudos de benchmarking�Projetos “fail-safe” (falhando, não coloca em risco)�Projeto de materiais normalizados (internos e externos)�Documentação (registros das melhores práticas, lições aprendidas, etc, e projetos similares)�Estudos de simulação (análises de conceitos, para estabelecer os requisitos do projeto)�Dispositivos à prova de erro

Exemplos de “controle de projeto”Modo

de falha

Causa Controles de

prevenção

Controles de

detecção

O veículo não para Quebra da ligação mecânica

do freio, devido à proteção corrosiva inadequada.

Projetado para o material normalizado MN-845.

Ensaio na condição de tensão 03-9963.

Cilindro principal de vácuo fechado, devido ao projeto

do selo.

Projeto “carry-over”, com os mesmos requisitos de ciclos obrigatórios.

Ensaios de variação de pressão, ao nível do sistema.

Perda do fluído hidráulico através da linha, devido àespecificação de torque

errado do conector.

Projetado para os requisitos de torque TO 3993.

Ensaio de vibração por rampa de tensão 18-1950.

Perda do fluído hidráulico, devido à linha estar

obstruída, comprimida, especificação inadequada

do material do tubo.

Projetado para o material normalizado MN-1178.

DOE – resiliência do tubo.

“Detecção” no DFMEA

� É a estimativa da probabilidade de se detectar a falha, baseando-se nas formas decontrole detectivos existentes.

� Existe um índice de detecção, que é a capacidade do controle atual do projetoidentificar uma deficiência em potencial do projeto, antes que os desenhos sejamliberados para produção.

� Para esse índice, há uma escala variando de 1 a 10. O valor 1 é reservado para aprevenção da falha, através de soluções de projeto comprovados.

10

1

Detecção totalmente incerta:

Detecção quase certa:

“Índice de Detecção” (D) – Parte 1Oportunidade para a

detecçãoCritério: Probabilidade de detecção pelo controle de projeto Pontos Probabilidade de

detecção

Nenhuma oportunidade de detecção

Nenhum controle atual de projeto. Não se pode detectar, ou não éanalisado.

10 Quase impossível

Não há a possibilidade de detectar, em qualquer estágio

Análises do projeto e controles de detecção têm uma fraca capacidade de detecção. Análises virtuais (ex.: CAE, FEA, etc), não são correlacionadas às condições atuais de operações.

9 Muito remota

“Post” projeto congelado, e antes do lançamento

A verificação / validação do produto, depois do projeto congelado, e antes do lançamento, com ensaios de pass/fail (ensaios no sub-sistema ou sistema, com critério de aceitação, tal como montagem e manuseio, avaliação de transporte, etc).

8 Remota

A verificação / validação do produto, depois do projeto congelado, e antes do lançamento, com ensaios de falhas (ensaios no sub-sistema ou sistema, até a falha ocorrer, ensaios de interações de sistemas, etc).

7 Muito baixa

A verificação / validação do produto, depois do projeto congelado, e antes do lançamento, com ensaios de degradação (ensaios no sub-sistema ou sistema depois do ensaio de durabilidade, por exemploverificação funcional.)

6 Baixa

“Índice de Detecção” (D) – Parte 2Oportunidade

para a detecção

Critério: probabilidade de detecção pelo controle de projeto

Pontos Probabilidade de detecção

Antes do congelamento do projeto

A validação do produto (ensaio de confiabilidade, desenvolvimento ou validação), antes do congelamento do projeto, usando ensaios pass/fail (exemplos: critério de aceitação para o desempenho, verificação funcional, etc).

5 Moderada

A validação do produto (ensaio de confiabilidade, desenvolvimento ou validação), antes do congelamento do projeto, usando ensaios de falha (exemplos: até a quebra, rendimento, rachar, etc).

4 Altamente moderada

A validação do produto (ensaio de confiabilidade, desenvolvimento ou validação), antes do congelamento do projeto, usando ensaios de degradação (exemplos: tendência de dados, valores antes e depois, etc).

3 Alta

Análises virtuais correlatas

Análise do projeto / controle de detecção tem uma capacidade forte de detecção. Análise virtual (ex.: CAE, FEA, etc.) é altamente correlacionada com a condição atual, ou esperada de operação, antes do congelamento do projeto.

2 Muito alta

Detecção não éaplicável, prevenção da falha

A causa da falha ou modo de falha não pode ocorrer, porque éaltamente preventivo, através das soluções de projeto (exemplos: normas de projeto comprovadas, melhores práticas ou materiais comuns, etc).

1 Quase certa

“Número de Prioridade de Risco” (NPR)no DFMEA

� É o produto dos índices de Severidade, Ocorrência e Detecção.

� Para seu cálculo, utiliza-se o maior índice de severidade, o índice de ocorrência e omenor índice de detecção.

� Independentemente do NPR resultante, atenção especial deve ser dedicada, quando aseveridade é elevada.

� Quando a severidade é 9 ou 10, é imperativo que a equipe deve garantir que o riscoseja considerado, através dos controles de projeto existentes, ou ações recomendadas.

� Para modos de falhas com severidade ≤ 8 a equipe deveria considerar as causas quetenham as maiores ocorrências ou detecções.

NPR (S) Severidade

(O) Ocorrência

(D)DetecçãoX X=

“Número de Prioridade de Risco” (NPR)

� O uso de uma nota de corte de NPR, NÃO é recomendação prática para adeterminação da necessidade de ações.

� Aplicando-a, assume-se que o NPR é uma medida de relativo risco (não éfreqüente) e que as melhorias contínuas não são requeridas (são).

� Se uma nota de corte de 100 for escolhida, por exemplo, veja o que poderiaocorrer (a alternativa “B” seria escolhida, incorretamente!):

� Classificação no DFMEA:

� Características críticas / de segurança, em potencial: ∇∇∇∇

� Características significativas, em potencial: S

Item Severidade Ocorrência Detecção NPR

A 9 2 5 90

B 7 4 4 112

“Ações Recomendadas” no DFMEA

Índice Alto de Severidade

� Somente alterações de projeto, fazendo com que desapareça o modo de falha.

Índice Alto de Ocorrência

� Dispositivo à prova de erro (Poka Yoke)

� Revisão do GD&T do projeto

� Revisão do projeto, para diminuir a tensão ou trocar componentes fracos (probabilidade alta de falha)

� Adicionar redundâncias, e revisão da especificação do material

Índice Alto de Detecção

� DOE (Delineamento de experimentos)

� Revisão do plano de ensaios, e ensaios de confiabilidade

� Resultados de revisões de projetos

� Resultados de análises de confiabilidade, modificações de uma dada norma de engenharia ou guia de projetos

� Análises de projeto, desenhos, esquemas ou modelos, para confirmar as mudanças físicas da característica alvo

“Ações Recomendadas” no DFMEA

Ações recomendadas Causa Modo de falha

1º2º

Severidade

Ocorrência

Detecção

Modo de Falha

Causa

Controle

“Follow up das ações”

Pode ser realizado de diversas maneiras, como:

� Verificar se os requerimentos do projeto foram acabados;

� Revisar desenhos e especificações de engenharia;

� Revisar o FMEA de Processo, bem como os Planos de Verificação.

Fim do Módulo 2