
















Estude fácil! Tem muito documento disponível na Docsity
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
Prepare-se para as provas
Estude fácil! Tem muito documento disponível na Docsity
Prepare-se para as provas com trabalhos de outros alunos como você, aqui na Docsity
Encontra documentos específicos para os exames da tua universidade
Prepare-se com as videoaulas e exercícios resolvidos criados a partir da grade da sua Universidade
Responda perguntas de provas passadas e avalie sua preparação.
Ganhe pontos para baixar
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
O que é a confiabilidade de um produto
Tipologia: Notas de estudo
1 / 24
Esta página não é visível na pré-visualização
Não perca as partes importantes!

















http://en.wikipedia.org/wiki/Reliability_engineering
Engenharia de confiabilidade é a engenharia que enfatiza a confiabilidade na gestão do ciclo de vida de um produto. Descreve a capacidade de um sistema ou componente para funcionar sob condições estabelecidas por um determinado período de tempo. Teoricamente definida como a probabilidade de falha, a freqüência de falhas, ou em termos de disponibilidade, uma probabilidade derivada da confiabilidade e facilidade de manutenção. Desempenha um papel fundamental na relação custo-eficácia dos sistemas. Apesar de ser definida e afetada por parâmetros estocásticos, de acordo com alguns especialistas reconhecidos, qualidade, confiabilidade e segurança não são alcançados por matemática e estatística. Quase todo ensino e literatura sobre o tema enfatiza estes aspectos, e ignora a realidade de que os intervalos de incerteza envolvidos invalidar grande parte métodos quantitativos para a previsão e medição.
Análise de risco a confiabilidade, Modo de falha e análise de efeitos (FMEA), Modos de falha, os mecanismos e análise de efeitos (FMMEA), Análise da árvore de falhas (FTA), Cálculos de estresse e desgaste de material, Fadiga e análise de fluência, Análise de elementos finitos, Análise térmica (stress), Análise de corrosão, Análise de erro humano, Estimativas de incerteza estatística, Simulações de Monte Carlo, Manutenção centrada de confiabilidade (RCM), Elaboração de relatórios e gestão de ações corretivas.
Devido ao grande número de técnicas de confiabilidade, sua despesa, e os diferentes graus de confiabilidade necessária para situações diferentes, a maioria dos projetos desenvolve programas de confiabilidade para especificar as tarefas de confiabilidade que serão executadas para um sistema específico.
http://en.wikipedia.org/wiki/Reliability_engineering
Um plano de programa de confiabilidade também pode ser usado para avaliar e melhorar a disponibilidade de um sistema pela estratégia de se concentrar em aumentar a capacidade de teste e de manutenção e não na confiabilidade. Melhorar a capacidade de manutenção é geralmente mais fácil do que a confiabilidade. Estimativas de mantenabilidade (taxas de reparação) também são geralmente mais precisos. No entanto, porque as incertezas nas estimativas de confiabilidade são na maioria dos casos, muito grande, é provável que dominem a disponibilidade (incerteza predição) do problema; mesmo no caso de os níveis de capacidade de manutenção serem muito elevados.
Quando a confiabilidade não está sob controle, as questões mais complicadas podem surgir, como a mão de obra (capacidade de serviços de mantenedores / cliente) escassez, disponibilidade de peça sobressalente, os atrasos de logística, a falta de instalações de reparação, extensiva renovação de equipamentos, amplos custos de gerenciamento de configuração e outros. O problema da falta de confiabilidade pode ser aumentada também devido ao "efeito dominó", de falhas de manutenção induzido após reparos.
Só com foco em manutenibilidade não é, portanto, suficiente. Se as falhas são evitadas, nenhum dos outros são de alguma importância e, portanto, a confiabilidade é geralmente considerada como a parte mais importante da disponibilidade. A confiabilidade precisa ser avaliada e melhorada relacionada tanto a disponibilidade e o custo de propriedade (devido ao custo de peças de reposição, manutenção de horas-homem, custos de transporte, o custo de armazenamento, risco de partes obsoletas, etc.) Mas, como a GM e a Toyota têm tardiamente descoberto, TCO também inclui os custos de responsabilidade, os cálculos de confiabilidade não são suficientes ou precisam enfrentar riscos corporais pessoais dos clientes.
Frequentemente uma compensação é necessária entre os dois. Pode haver uma relação máxima entre a disponibilidade e custo de propriedade. Testabilidade de um sistema também deve ser abordada no plano como este é o link entre a confiabilidade e facilidade de manutenção. A estratégia de manutenção pode influenciar a confiabilidade de um sistema (por exemplo, a manutenção preventiva e / ou preditiva), embora nunca pode trazê-lo acima da confiabilidade inerente.
O plano de confiabilidade deve fornecer claramente uma estratégia para o controle de disponibilidade. A importância da disponibilidade ou custo de manutenção depende da utilização do sistema. Por exemplo, um sistema que é um elo importante em um sistema de produção - por exemplo, uma plataforma de petróleo grande - normalmente é permitido ter um alto custo de propriedade se isso se traduz em até um pequeno aumento na disponibilidade, como a indisponibilidade dos resultados de plataforma em uma enorme perda de receita que pode facilmente exceder o alto custo de propriedade. Um plano de confiabilidade apropriado deve sempre tratar a análise RAMT (Reliability, Availability, Maintainability and Testability) em seu contexto total. RAMT significa, neste caso, para a confiabilidade, disponibilidade, manutenção / facilicade de manutenção e testabilidade em contexto para as necessidades dos clientes.
http://en.wikipedia.org/wiki/Reliability_engineering
Para qualquer sistema, uma das primeiras tarefas da Engenharia de Confiabilidade é especificar adequadamente os requisitos de confiabilidade e manutenibilidade (Facilidade de Manutenção) decorrentes das necessidades globais de disponibilidade e, mais importante, a partir de análise de falha própria ou resultados preliminares dos testes. Definir somente metas de disponibilidade não é apropriado. Requisitos de confiabilidade tratam o próprio sistema, incluindo teste e requisitos de avaliação e tarefas e documentação associada. Requisitos de confiabilidade são incluídos no sistema adequado ou especificações de requisitos de subsistemas, planos de teste e declarações contratuais. A criação de condições adequadas de nível inferior é crítica.
Fornecimento de apenas objetivos mínimos quantitativos (por exemplo, valores de MTBF^1 / taxas de falha) não é suficiente, por diferentes razões. Uma razão é que a validação completa (relacionada à correção e verificabilidade no tempo) de uma alocação de confiabilidade quantitativa (exigência de especificações) nos níveis mais baixos para os sistemas complexos podem (muitas vezes) não ser feitas, como conseqüência de 1) O fato de que as exigências são probabalisticas e 2) o alto nível de incertezas envolvidas para o cumprimento de todos os requisitos probabilisticos 3) Boas estimativas de um (probabilistico) número de confiabilidade por item estão disponíveis apenas muito tarde no projeto, às vezes até só muitos anos após o uso em serviço.
Compare este problema com o contínuo (des)equilíbrio de, por exemplo, os requisitos de massa do sistema de baixo nível no desenvolvimento de uma aeronave, que já é muitas vezes uma grande empresa. Observe que, neste caso, as massas não só diferem em termos de apenas alguns % e esses dados já não são probabilísticos e está disponível em modelos CAD. Em caso de confiabilidade, os níveis de insegurança (taxas de falha) podem mudar em questão de décadas (1000 de %), como resultado de desvios muito menores no projeto, processo ou qualquer outra coisa.
A informação muitas vezes não está disponível sem enormes incertezas na fase do desenvolvimento. Isto faz este problema de alocação quase impossível de fazer de uma forma útil, prático, válida, que resulta em enorme ou sub-especificação. É portanto necessária uma abordagem pragmática. Por exemplo; o uso de níveis gerais / classes de requisitos quantitativos só dependendo da gravidade dos efeitos de falha. Além disso, a validação dos resultados é uma tarefa muito mais subjetiva do que para qualquer outro tipo de exigência. (Quantitativa) parâmetros de Confiabilidade - em termos de MTBF - são, de longe, os parâmetros de design mais incertos em qualquer projeto.
Além disso, os requisitos de concepção de confiabilidade devem conduzir um projeto (sistema ou em parte) para incorporar características que impedem que as falhas ocorram ou limitar as consequências da falha em primeiro lugar!
(^1) MTBF ("Mean Time Between Failures") ou período médio entre falhas é um valor atribuído a um determinado dispositivo ou aparelho para descrever a sua confiabilidade. Este valor atribuído indica quando poderá ocorrer uma falha no aparelho em questão. Quanto maior for este índice, maior será a confiabilidade no equipamento e, consequentemente, a manutenção será avaliada em questões de eficiência.
http://en.wikipedia.org/wiki/Reliability_engineering
Na prática, a maioria das falhas pode, no final, ser rastreada até a raiz da causa de qualquer tipo de erro humano. Por exemplo, erros humanos em:
Estudos de uso, Análise de requisitos / configuração, Controle de configuração, Pressupostos, Análise de cálculos / simulações / FEM, Projeto, Desenhos de projeto, Testes (carregar configurações incorretas ou medição falha), Análise estatística, Fabricação, Controle de qualidade, Manutenção, Manuais de manutenção, Retorno incorreto de informações, Etc.
No entanto, os seres humanos também são muito bons na detecção de (os mesmos) falhas, correção de falhas e improvisar quando ocorrerem situações anormais. A política de que as ações humanas devem ser completamente descartada de qualquer processo de design e produção para melhorar a confiabilidade pode não ser eficaz, portanto.
Algumas tarefas são melhor realizadas por seres humanos e algumas são melhor realizadas por máquinas. Além disso, os erros humanos em gestão e organização de dados e informações ou uso indevido ou abuso de itens também podem contribuir para a falta de confiabilidade.
Esta é a razão central por que altos níveis de confiabilidade para sistemas complexos só pode ser alcançado seguindo um robusto processo de engenharia de sistemas com adequado planejamento e execução das tarefas de validação e verificação. Isso também inclui a organização cuidadosa dos dados e compartilhamento de informações. A criação de uma "cultura de confiabilidade" no mesmo sentido como tendo uma "cultura de segurança" é de suma importância para o desenvolvimento de sistemas críticos de segurança.
http://en.wikipedia.org/wiki/Reliability_engineering
O projeto para a confiabilidade começa com o desenvolvimento de um modelo (sistema). Modelos de confiabilidade e disponibilidade usam diagramas de blocos e árvores de falhas para fornecer um meio gráfico de avaliar as relações entre as diferentes partes do sistema.
Estes modelos podem incorporar previsões com base em taxas de insucesso tomadas a partir de dados históricos. Enquanto as (dados de entrada) previsões nem sempre são precisas em um sentido absoluto, são valiosas para avaliar as diferenças relativas nas alternativas de projeto. Parâmetros de manutenção, MTTR^2 por exemplo, são outros insumos para estes modelos.
As mais importantes causas fundamentais iniciais e mecanismos de falha devem ser identificados e analisados com ferramentas de engenharia. Um conjunto diversificado de orientação prática e desempenho prático e requisitos de confiabilidade devem ser fornecidos aos projetistas para que eles possam gerar projetos de baixo-stress e produtos que protegem ou estão protegidos contra danos e desgaste excessivo. Uma validação adequada de cargas de entrada (requisitos) e a verificação de "performance" da confiabilidade por meio de testes pode ser necessária.
Uma das técnicas de design mais importantes é a redundância. Isto significa que, se uma parte do sistema falhar, existe um caminho de sucesso alternativo, tal como um sistema de cópia de segurança. A razão para isso ser a escolha como projeto final está relacionada ao fato de que a evidência de alta confiança da confiabilidade para novas peças / itens muitas vezes não está disponível ou é extremamente caro de se obter.
Com a criação de redundância, juntamente com um alto nível de monitoramento de falhas e a prevenção de falhas de causa comum, até mesmo um sistema com relativo mau único canal (parte) de confiabilidade, pode ser feito altamente confiável (confiabilidade de missão) em nível de sistema. Nenhum teste de confiabilidade tem de ser exigido para isso.
Além disso, usando a redundância, diferente design e processos de fabricação (de diferentes fornecedores) para os canais individuais independentes, uma menor sensibilidade para as questões de qualidade (falhas prematuras) será criada e níveis muito elevados de confiabilidade podem ser alcançado em todos os momentos dos ciclos de desenvolvimento (tempos de início da vida e longo prazo).
(^2) Mean Time To Repair (MTTR) é uma medida básica da capacidade de manutenção de itens reparáveis. Isto representa o tempo médio necessário para reparar um componente ou dispositivo que falhou. [1] Expresso matematicamente, é o tempo de manutenção corretiva total dividido pelo número total de ações de manutenção corretiva, durante um determinado período de tempo. [2] geralmente não inclui o tempo de espera para as peças não prontamente disponíveis ou outras perdas de tempo administrativas ou logísticas.
http://en.wikipedia.org/wiki/Reliability_engineering
Análise funcional e de falhas funcionais Análise de Manutenção Preditiva e Preventiva Análise de Testabilidade Análise de Diagnóstico de Falhas (normalmente também incorporado em FMEA) Análise de Erros Humanos Análise de Risco Operacional Triagem Manual Apoio Logístico Integrado
Os resultados são apresentados nas revisões de projeto de sistema e comentários de logística. A Confiabilidade é apenas uma exigência entre muitos requisitos do sistema. Estudos de compensação da engenharia são usados para determinar o equilíbrio ideal entre a confiabilidade e outros requisitos e restrições.
Previsão de confiabilidade é a combinação da criação de um modelo de confiabilidade adequado juntamente com a estimativa (e justificação) dos parâmetros de entrada para este modelo (como taxas de falha para um modo de falha particular ou evento eo tempo médio para reparar o sistema de uma falha particular) e, finalmente, para fornecer uma estimativa a nível de sistema (ou parte) para os parâmetros de confiabilidade de saída (de disponibilidade do sistema ou de uma freqüência particular de falha funcional).
Alguns especialistas em engenharia de confiabilidade reconhecidos - como Patrick O'Connor, R. Barnard - argumentaram que muita ênfase é dada frequentemente para a predição dos parâmetros de confiabilidade e um maior esforço deve ser dedicado à prevenção de falhas (melhoria de confiabilidade). Em teoria, não há limite inerente e uma maior confiabilidade não necessita ser mais onerosa em desenvolvimento. Outro de seus argumentos é que a previsão de confiabilidade com base em dados históricos pode ser muito enganador, como uma comparação só é válida para exatamente os mesmos projetos, produtos, processos de fabricação e manutenção sob exatamente as mesmas cargas e contexto ambiental. Mesmo uma pequena alteração em detalhes em qualquer um deles poderia ter grandes efeitos sobre a confiabilidade. Além disso, normalmente os itens mais suspeitos e importantes (candidatos mais interessantes para uma investigação de confiabilidade) são mais frequentemente sujeitos a muitas modificações e alterações.
Projetos de engenharia são na maioria das indústrias atualizados com freqüência. Esta é a razão pela qual o padrão (re-ativo ou pró-ativo) de métodos estatísticos e processos, como utilizado na indústria médica ou ramo de seguro não são tão eficazes para a engenharia. Um outro argumento surpreendente, mas lógico é que, para ser capaz de prever com precisão a confiabilidade através de testes, os mecanismos exatos de falha devem ser conhecidos na maioria dos casos e, por conseguinte, - na maioria dos casos, - podem ser evitados!
http://en.wikipedia.org/wiki/Reliability_engineering
Seguindo a rota errada, tentando quantificar e resolver um problema complexo de engenharia de confiabilidade em termos de MTBF ou Probabilidade e usando a abordagem de re-ativo é referido por Barnard como "o jogo dos números" e é considerado como uma prática ruim.
Para sistemas já existentes, é possível argumentar que os programas responsáveis analisariam diretamente e tentariam corrigir a causa raiz de falhas descobertas e, assim, poderiam tornar a estimativa inicial MTBF totalmente inválido como novos pressupostos (sujeito a altos níveis de erro) do efeito da correção / reformulação necessária. Outra questão prática diz respeito a uma generalizada falta de disponibilidade de dados de falha detalhados e não filtragem consistente de dados de falha (feedback) ou desconsideração de erros estatísticos, que são muito altos para eventos raros (como falhas relacionadas a confiabilidade).
Diretrizes muito claras devem estar presentes para poder contar e comparar as falhas, relacionadas a diferentes tipos de causas raízes (por exemplo, fabricação de, a manutenção, transporte-, falhas de projeto inerentes ou induzidas pelo sistema). Comparando diferentes tipos de causas podem levar a estimativas e decisões de negócios incorretas sobre o foco de melhoria.
Executar uma previsão adequada de confiabilidade quantitativa para sistemas pode ser difícil e muito dispendioso se for feito por meio de testes. Em nível de peça, os resultados podem ser obtidos freqüentemente com maior confiança já que muitas amostras podem ser utilizadas para os testes disponíveis no orçamento financeiro, no entanto, infelizmente, estes testes podem não ter validade em nível de sistema, devido aos pressupostos que tiveram que ser feitas para testar a nível de peça.
Estes autores argumentam que ele não pode ser enfatizado o suficiente para que o teste de confiabilidade se deve fazer para criar falhas. Em primeiro lugar, aprender com eles e melhorar a peça / sistema. A conclusão geral é desenhada que um preciso e uma previsão absoluta - por comparação de dados de campo ou testes - da confiabilidade não é, na maioria dos casos, possível. Uma exceção podem ser falhas devido aos problemas causados como falhas de fadiga. Na introdução da MIL-STD-785 está escrito que a previsão de confiabilidade deve ser usada com muita cautela, se não for usado só para comparação em estudos de melhoria.
http://en.wikipedia.org/wiki/Reliability_engineering
Requisitos quantitativos são especificados usando parâmetros de confiabilidade. O parâmetro mais comum de confiabilidade é o tempo médio para falha (MTTF), que também pode ser especificado como a taxa de falhas (isto é expresso como uma frequência ou função de densidade da probabilidade condicional (PDF)) ou o número de falhas durante um determinado período.
Estes parâmetros são muito úteis para os sistemas que são operados com freqüência, como a maioria dos veículos, máquinas e equipamentos eletrônicos. A confiabilidade aumenta com o aumento do MTTF. O MTTF é normalmente especificado em horas, mas também pode ser utilizado com outras unidades de medida, tais como milha ou ciclos.
Em outros casos, a confiabilidade é especificada como a probabilidade de sucesso da missão. Por exemplo, a confiabilidade de um vôo da aeronave programado pode ser especificado como uma probabilidade adimensional ou uma porcentagem, como na engenharia de segurança do sistema.
Um caso especial de sucesso de missão é o dispositivo de um único tiro ou sistema. Estes são os dispositivos ou sistemas que permanecem relativamente dormente e só operam uma vez. Exemplos incluem airbags de automóveis, pilhas térmicas e mísseis. A confiabilidade de um único tiro é especificado como uma probabilidade de sucesso único, ou é subsomado em um parâmetro relacionado.
A confiabilidade de um míssil de tiro único pode ser especificada como um requisito para a probabilidade de um acerto. Para tais sistemas, a probabilidade de falha na demanda (PFD) é a medida de confiabilidade - o que na verdade é um número de indisponibilidade. Este PFD é derivado da taxa de falha (a freqüência de ocorrência) e tempo de missão para sistemas não reparáveis.
Para sistemas reparáveis, é obtido a partir de taxa de falhas e tempo médio de reparação (MTTR) e intervalo de teste. Esta medida não pode ser única para um dado sistema dado que esta medida depende do tipo de pedido. Além dos requisitos de nível de sistema, requisitos de confiabilidade podem ser especificados para subsistemas críticos. Na maioria dos casos, os parâmetros de confiabilidade são especificados com intervalos de confiança estatísticos apropriados.
http://en.wikipedia.org/wiki/Reliability_engineering
A modelagem da Confiabilidade é o processo de prever ou compreender a confiabilidade de um componente ou sistema antes de sua implementação. Dois tipos de análise que são muitas vezes utilizados para modelar um sistema completo de disponibilidade (incluindo os efeitos de problemas de logística, como aprovisionamento de peças de reposição, transporte e mão de obra) são a análise de árvore de falhas e diagramas de blocos de confiabilidade.
A nível de componente o mesmo tipo de análise pode ser utilizado em conjunto com os outros. A entrada para os modelos podem vir de várias fontes: testes, dados de campo de experiências operacionais anteriores ou manuais de dados da mesma ou produções mistas podem ser usados.
Em todos os casos, os dados devem ser usados com muito cuidado, pois as previsões são válidas apenas quando é usado o mesmo produto no mesmo contexto. Muitas vezes, as previsões são feitas apenas para comparar alternativas.
No caso de previsões a nível da peça, dois campos distintos de investigação são comuns:
A física de abordagem de falha usa uma compreensão dos mecanismos de falha físicos envolvidos, tais como a propagação de fissuras mecânicas ou degradação, corrosão química ou falha;
A abordagem do modelo de stress para peças é um método empírico para a previsão com base na contagem do número e tipo de componentes do sistema, e a tensão a que são submetidos durante o funcionamento.
Confiabilidade de software é a área mais desafiadora que deve ser considerada quando se é um componente importante para a funcionalidade do sistema.
http://en.wikipedia.org/wiki/Reliability_engineering
O objetivo do teste de confiabilidade é descobrir potenciais problemas com o projeto tão cedo quanto possível e, em última instância, fornecer a confiança de que o sistema cumpre os seus requisitos de confiabilidade.
Testes de Confiabilidade podem ser realizados em vários níveis e existem diferentes tipos de testes. Os sistemas complexos podem ser examinados a nível do componente, placa de circuito, unidade, conjunto, subsistema e sistema. A nomenclatura do nível de teste varia entre as aplicações. Por exemplo, a realização de testes de triagem de estresse ambiental em níveis mais baixos, como em peças ou pequenas montagens, pega os problemas antes que eles causem falhas em níveis mais elevados. No entanto, o teste não atenua o risco da falta de confiabilidade.
Em cada ensaio, tanto uma estatística de erros do tipo 1 e do tipo 2 pode ser feita, e depende do tamanho da amostra, o tempo de teste, a relação de pressupostos e discriminação necessária. Há risco de aceitar incorretamente um design ruim (erro tipo 1) e o risco de rejeitar incorretamente um bom projeto (erro tipo 2).
Nem sempre é viável testar todos os requisitos do sistema. Alguns sistemas são proibitivamente caros para testar; alguns modos de falha podem levar anos para para serem observados; algumas interações complexas resultam em um grande número de possíveis casos de teste; e alguns testes requerem a utilização de gamas limitadas de teste ou outros recursos. Nestes casos, diferentes abordagens para testes podem ser utilizados, tais como testes (altamente) acelerados de vida, planejamento de experimentos e simulações.
O nível desejado de confiança estatística, também desempenha um papel no teste de confiabilidade. A confiança estatística é aumentada através do aumento tanto do tempo de teste ou do número de elementos testados.
Planos de teste de confiabilidade são projetados para atingir a confiabilidade especificada no nível de confiança especificado com o número mínimo de unidades de teste e tempo de prova. Planos de teste diferentes resultam em diferentes níveis de risco para o produtor eo consumidor. A confiabilidade desejada, confiança estatística, e os níveis de risco para cada lado influenciam o plano de teste final. O cliente eo desenvolvedor devem concordar com antecedência sobre a forma como os requisitos de confiabilidade serão testados.
http://en.wikipedia.org/wiki/Reliability_engineering
Um aspecto fundamental do teste de confiabilidade é definir "falha". Embora isso possa parecer óbvio, há muitas situações em que não é claro se uma falha é realmente culpa do sistema. As variações nas condições de teste, diferenças de operador, tempo e situações inesperadas criam diferenças entre o cliente eo desenvolvedor do sistema.
Uma estratégia para resolver este problema é a utilização de um processo de conferência de pontuação. A conferência de pontuação inclui representantes do cliente, o desenvolvedor, a organização do ensaio, a organização da confiabilidade e observadores às vezes independentes. O processo de conferência de pontuação é definida na descrição do trabalho. Cada caso de teste é considerado pelo grupo e "avaliado" como um sucesso ou fracasso. Esta pontuação é o resultado oficial utilizado pelo engenheiro de confiabilidade.
Como parte da fase de requisitos, o engenheiro de confiabilidade desenvolve uma estratégia de teste com o cliente. A estratégia de teste faz um balanceamento entre as necessidades da organização de confiabilidade, que quer o máximo de dados possíveis, e restrições, tais como custos, prazos e recursos disponíveis.
Planos e procedimentos de teste são desenvolvidos para cada teste de confiabilidade, e os resultados são documentados.
A finalidade do teste de vida acelerada (ALT - Accelerated Life Test) é induzir falha de campo em laboratório a uma taxa muito mais rápida, proporcionando um ambiente mais severo, mas mesmo assim representativo. Nesse teste, o produto é esperado para falhar em laboratório assim como teria falhado em campo, mas em muito menos tempo. O principal objetivo de um teste acelerado é uma das seguintes opções:
Descobrir modos de falha Prever a vida normal em campo através de um teste de vida de alto estresse em laboratório.
Um programa de teste acelerado pode ser dividido nas seguintes etapas:
Definir objetivos e escopo do teste Coletar informações necessárias sobre o produto Identificar os estresses e determinar os níveis Realizar o teste acelerado e analisar os dados coletados.
Formas comuns de determinar uma relação de estresse da vida são:
Modelo de Arrhenius Modelo de Eyring Modelo de lei de potência inversa Modelo de Temperatura-Umidade Modelo não-térmico de temperaturar
http://en.wikipedia.org/wiki/Reliability_engineering
Outros indicadores de software, tais como a complexidade, também são utilizados. Esta métrica permanece controversa, uma vez que mudanças no desenvolvimento de software e práticas de verificação podem ter um impacto dramático sobre as taxas gerais de defeitos.
O teste é ainda mais importante para o software do que para o hardware. Mesmo os melhores processos de desenvolvimento de software resulta em algumas falhas de software que são quase indetectáveis até serem testados. Tal como acontece com o hardware, o software é testado em vários níveis, a começar com unidades individuais, por meio da integração e testes com capacidade total do sistema.
Ao contrário do hardware, não é aconselhável saltar níveis de teste de software. Durante todas as fases de testes, falhas de software são descobertas, corrigidas e re-testadas. Estimativas de confiabilidade são atualizados com base na densidade de falhas e outras métricas. Ao contrário do hardware, fazendo exatamente o mesmo teste com exatamente a mesma configuração do software não fornecem maior confiança estatística.
Em vez disso, a confiabilidade do software usa diferentes métricas, tais como cobertura de código. Eventualmente, o software é integrado com o hardware do sistema de nível superior e a confiança de software é subsumida pela confiabilidade do sistema.
http://en.wikipedia.org/wiki/Reliability_engineering
Engenharia da confiabilidade difere da engenharia de segurança no que diz respeito ao tipo de riscos que são considerados. Engenharia de confiabilidade está, no final, apenas preocupado com o custo. Relaciona-se com todos os riscos da confiabilidade que poderiam se transformar em incidentes com um determinado nível de perda de receita para a empresa ou o cliente. Estes podem ser custo devido à perda de produtiva em função da indisponibilidade do sistema, demandas altas ou baixas inesperadas para peças de reposição, os custos de reparação, horas- homem, (múltiplos) re-projetos, interrupções na produção normal (por exemplo, devido aos tempos de reparação elevados ou devido às inesperadas demandas de peças sobressalentes não estocadas) e muitos outros custos indiretos.
Engenharia de segurança, por outro lado, é mais específica e regulada. Relaciona-se só com os perigos muito específicos e sistemas de segurança que poderiam levar a acidentes graves e está principalmente preocupado com a perda de vidas, perda de equipamento, ou danos ambientais. Os requisitos relacionados ao sistema de confiabilidade funcional são, por vezes, extremamente elevados. Ela lida com eventos perigosos indesejados (para a vida, a propriedade eo meio ambiente), na mesma acepção que a engenharia de confiabilidade, mas normalmente não olha diretamente para os custos e não se preocupa com ações de reparo após a falha / acidentes (em nível de sistema). Outra diferença é o nível de impacto das falhas na sociedade e no controle de governos. A Engenharia de segurança é muitas vezes rigorosamente controlada pelos governos (por exemplo nucleares, aeroespaciais, de defesa, ferroviário e petróleo indústrias).
Além disso, a engenharia de segurança e a engenharia de confiabilidade podem até ter exigências contraditórias. Trata-se de escolhas de arquitetura de nível de sistema. Wikipedia – exemplo: em sistemas de controle de sinal de trem é uma prática comum utilizar um conceito à prova de falhas do sistema. Neste conceito a falha do lado errado precisa ser totalmente controlada a uma extrema taxa baixa de falhas. Essas falhas estão relacionadas a possíveis efeitos graves, como colisões frontais (2 lâmpadas verdes). Os sistemas são projetados de forma que a grande maioria das falhas simplesmente resultem em uma perda temporária ou total dos sinais ou dos contatos abertos de relés e gerem luzes vermelhas para todos os trens. Este é o estado seguro. Todos os trens são parados imediatamente. Esta lógica à prova de falhas pode infelizmente reduzir a confiabilidade do sistema. A razão para isso é o maior risco de falso disparo, já que qualquer falha total ou temporária, ou intermitente é rapidamente travada em um estado desligado (seguro). Diferentes soluções estão disponíveis para esta questão.