See a worldwide directory.

 

ReliaSoft > Reliability Hotwire >  Edição 22 > Conceitos Básicos de Confiabilidade
Reliability HotWire: eMagazine for the Reliability Professional
Reliability HotWire

Edição 22, Dezembro 2006

Conceitos de Confiabilidade
Especificações e Definições das Falhas dos Produtos

Antes dos dados de vida serem analisados ou mesmo coletados, a definição de falha deve ser estabelecida. Enquanto isto parece como um conselho simplista e óbvio, a falta de definições geralmente aceitas para falhas pode resultar em engano sob a validação e especificações de confiabilidade, desperdiçando tempo de teste e recursos. O processo de caracterizar a confiabilidade e de definir as falhas para um produto é relacionado diretamente à missão do produto.

Um texto de definição da confiabilidade é:

A probabilidade condicional, para um dado nível de confiança, que o equipamento irá realizar suas funções pretendidas satisfatoriamente ou sem falha, isto é, dentro dos limites de performance especificados, para um dado tempo, para um período de tempo específico, função de tempo ou um tempo de missão, quando usado nas formas e propósitos pretendidos enquanto durar a operação e aplicação e operação com seus níveis de estresse associados. [1]

Com as todas as circunstâncias removidas, isto resume-se para definição de confiabilidade como a probabilidade do produto executar sua missão pretendida sem falhar. A definição da confiabilidade lança-se diretamente para missão do produto, que a falha de produto é a incapacidade do produto executar sua missão definida.

Especificações de Confiabilidade

A fim desenvolver um bom programa de confiabilidade para um produto, ele deve ter boas especificações de confiabilidade. Estas especificações devem dirigir-se a maioria, se não todas, condições na definição da confiabilidade acima, incluindo o tempo da missão, as limitações de uso, o ambiente de operação, etc.. Em muitos casos, isto requer uma descrição detalhada de como é esperada a performance prévia da confiabilidade do produto. O uso de uma única medida, tal como o MTBF, como sendo a única medida de confiabilidade é inadequado. A especificação de que um produto será "não pior" do que o modelo anterior também é insuficiente. Uma especificação de confiabilidade ambígua permite uma grande parcela para o erro, e isto pode resultar em um produto que alcança o campo como mal compreendido e não-confiável. Naturalmente, pode haver situações onde falta uma organização do conhecimento da confiabilidade ou história para definir facilmente as especificações de confiabilidade de um produto. Nestas circunstâncias, uma análise dos dados existentes dos produtos anteriores pode ser necessária. Se existir informação suficiente para caracterizar o desempenho da confiabilidade de um produto anterior, deve ser uma questão relativamente simples transformar a confiabilidade histórica do produto em especificações do desempenho desejado da confiabilidade do novo produto. Os interesses financeiros terão que definitivamente serem tomados do cliente ao formular especificações da confiabilidade. Planejamento para custo de garantia e produção de peça é uma parte significativa do planejamento financeiro para liberação de um produto novo. Baseado em entradas financeiras tais como estes, um retrato da confiabilidade requerida para um novo produto pode ser estabelecida. Entretanto, o ansioso pensamento financeiro não deve ser a única determinante das especificações da confiabilidade, porque pode conduzir à problemas tais como objetivos não realísticos, as especificações que mudam uma base regular para ajustar os resultados do teste que começam a pegar outros fundos a fim se conformar com as expectativas não-realísticas. É necessário acoplar os objetivos financeiros do produto com uma boa compreensão do desempenho de produto a fim começar uma especificação realística para confiabilidade do produto. Um contrapeso apropriado dos objetivos financeiros e das expectativas realísticas do desempenho é necessário para desenvolver uma especificação detalhada e equilibrada da confiabilidade.

Definições Universal de Falhas

Um outro fundamento importante para um programa de confiabilidade é o desenvolvimento de definições universalmente combinadas de falha de produto. Isto pode parecer um pouco simplório, que deve ser razoavelmente óbvio se um produto falhou ou não [2], mas é completamente necessário para um número de diferentes razões.

Uma das razões mais importantes é que diferentes grupos dentro de uma organização podem ter diferentes definições à respeito do que realmente constitui uma falha. Este é freqüentemente o caso quando comparando diferentes práticas de grupos de engenharia de projeto e manufatura. Os testes idênticos executados no mesmo produto por estes grupos podem produzir resultados radicalmente diferentes, simplesmente porque os dois grupos têm definições diferentes da falha de produto. Para um programa da confiabilidade ser eficaz, deve haver uma definição geralmente aceita de falha para uma organização inteira. Naturalmente, esta definição pode requerer pouca flexibilidade dependendo do tipo de produto, da fase do desenvolvimento, etc., mas contanto que seja familiar a todos e com definição de falha geralmente aceita, as comunicações serão mais eficazes e o programa de confiabilidade será mais fácil de controlar.

Um outro benefício de ter definições de falha universalmente aceitas é que irá minimizar a tendência de ponderar falhas ausentes em determinados testes. Isto pode ser um problema, particularmente durante o desenvolvimento de um produto, porque é uma tendência dos coordenadores e dos engenheiros de negligenciar ou diminuir a importância das modalidades de falha que são estranhas ou não facilmente replicáveis. Esta tendência é somente humana, e uma pessoa que gasta muito tempo desenvolvendo um produto às vezes justifica na hora de escrever uma falha estranha como um "pulso aleatório" ou como sendo devido a algum outro erro externo. Ter uma definição específica de falha que se aplique a tudo ou a maioria dos tipos de testes ajudará aliviar este problema. Entretanto, um grau de flexibilidade é chamado para na definição da falha, particularmente com produtos complexos que podem ter um número de modalidades de falha distintas. Por esta razão, pode ser aconselhável ter uma estrutura de multicamadas de definição de falha que possa acomodar os caprichos relativo a comportamento complexo do equipamento. A seguinte lista de categorias com níveis de falha é dada como exemplo:

  • Tipo I - Falha Os incidentes operacionais severos que resultam definitivamente em um atendimento técnico, como a falha de uma peça, funcionamento de um equipamento não-reparável, material de consumo que falhou/vazou antes de sua vida especificada, início de um ruído de outro problema crítico. Este constitui um modo de falha fundamental que requer o serviço de um técnico manutenção treinado para o reparo.

  • Tipo II - Intervenção - Alguma ocorrência não planejada ou falha da missão do produto que requer que o usuário ajuste manualmente ou intervenha de outra forma com o produto ou sua saída. Estas tendem a serem as "falhas incomodas" que podem ser recuperadas pelo cliente ou pelo suporte de um telefonema. Dependendo da natureza do modo de falha, grupos de falhas do Tipo II poderiam ser agrupadas e promovidas para Tipo I se excedessem uma freqüência predefinida de ocorrências.

  • Tipo III - Evento - Os eventos incluirão todas as ocorrências restantes que não se encaixaram nas ocorrências acima. Isto pode incluir os eventos que não podem ser diretamente classificados como falhas, mas cuja sua freqüência é de interesse para o usuário e pode ser aproveitado para uma análise estatística. Os exemplos incluem as falhas causadas pelo mal funcionamento do equipamento ou erro do operador.

Durante o teste, todas estas ocorrências devem ser registradas com códigos, para separar os três tipos de falhas. Outras saídas relacionadas a processos de teste, tais como desvios das plantas de teste, devem ser entradas em um registro separado do teste. Deve haver uma revisão oportuna das ocorrências registradas para segurar a classificação apropriada antes das medidas dos cálculo e dos relatórios.

[1] Kececioglu, Dimitri, Reliability Engineering Handbook, Vol. 1, Prentice-Hall, 1991.

[2] This is closely related to the concept of product mission. A good baseline definition of failure is the inability of the product to perform its mission. From that basic definition, more detailed categorizations of failure can be developed.

Copyright © 2005 ReliaSoft Brasil, TODOS DIREITOS RESERVADOS

 

[Home]   [Softwares]   [Treinamentos]   [Consultorias]   [Painel de Confiabilidade]   [A Empresa]   [Clientes]   [weibull.com]

Copyright ©1998-2006 ReliaSoft Brasil, Todos os Direitos Reservados
Última Alteração: 17-10-06
 

LEGAL [Termos de Uso] [Links]
[Privacidade das Informações]

Contate Webmaster
Tel:
+55 11 2177-5456