Reliability by Design aplicado a sistemas de engenharia: requisitos, arquitetura, redundância, causa comum, mantenabilidade, testabilidade, FMEA, Design Review e verificação.

Confira!

Reliability by Design é a aplicação sistemática de requisitos, análises e decisões de engenharia para que confiabilidade, disponibilidade, manutenibilidade e suporte não sejam avaliados apenas depois que o sistema entra em operação. A lógica é simples: características de dependabilidade são fortemente determinadas durante definição de requisitos, arquitetura, especificação, seleção de componentes, interfaces, acessibilidade, redundância, proteção, testes e preparação para manutenção.

Quando esses atributos entram tarde no projeto, a organização tende a compensar limitações de design com estoque, inspeções excessivas, contingências operacionais, intervenções difíceis ou redundâncias adicionadas posteriormente. O resultado pode ser tecnicamente funcional na entrega, mas caro, frágil ou difícil de sustentar ao longo do ciclo de vida.

Projetar para confiabilidade não significa buscar falha zero nem adicionar redundância indiscriminadamente. Significa transformar necessidades de serviço e consequências de falha em requisitos verificáveis e tomar decisões conscientes sobre arquitetura, componentes, margens, mantenabilidade, diagnóstico, suporte e evidências de desempenho.

O que é Reliability by Design

Reliability by Design, frequentemente associado a Design for Reliability — DfR, é uma abordagem de engenharia em que os atributos de dependabilidade são tratados como requisitos de projeto desde as fases iniciais. A IEC 60300-1:2024 estrutura dependabilidade como capacidade de um sistema, produto ou serviço desempenhar como requerido quando requerido, considerando o ciclo de vida e as interfaces entre aspectos técnicos, financeiros e de gestão.

Na prática, Reliability by Design conecta quatro perguntas:

  • que função o sistema precisa desempenhar e em quais condições;
  • por quanto tempo ou com qual nível de disponibilidade essa função deve estar acessível;
  • como o sistema pode falhar e quais consequências são aceitáveis;
  • como detectar, isolar, reparar, recuperar e sustentar o sistema quando houver degradação ou falha.

A resposta não pertence a uma única disciplina. Elétrica, automação, telecomunicações, mecânica, civil, software, operação, manutenção, segurança e suprimentos podem participar da dependabilidade do mesmo sistema.

Requisito de confiabilidade precisa nascer antes da solução

Um erro frequente é definir a arquitetura primeiro e perguntar depois qual confiabilidade ela oferece. O caminho mais robusto é inverter a lógica: definir a necessidade de serviço, estabelecer critérios e só então selecionar uma arquitetura capaz de atendê-los.

A IEC 60300-3-4:2022 orienta a especificação de requisitos quantitativos e qualitativos de confiabilidade, manutenibilidade, supportability e disponibilidade. Isso ajuda a distinguir metas vagas de requisitos verificáveis.

“Sistema altamente confiável” não é requisito técnico. Formulações melhores podem incluir:

  • disponibilidade operacional mínima para um período definido;
  • probabilidade de sucesso durante uma missão;
  • tempo máximo de restabelecimento para determinada classe de falha;
  • tolerância a falha simples em funções críticas;
  • limite de perda de capacidade em condição degradada;
  • necessidade de teste automático, diagnóstico ou indicação de falha;
  • acessibilidade e tempo de substituição de módulos críticos.

O requisito deve incluir contexto operacional. Temperatura, poeira, umidade, vibração, regime de carga, manobras, ciclos, qualidade de energia, perfil de tráfego, agressividade ambiental e capacidade da equipe de manutenção alteram o desempenho esperado.

Confiabilidade precisa ser especificada antes de ser verificada. Requisitos vagos como “alta disponibilidade” não orientam arquitetura, testes nem aceite técnico.

Conheça o serviço de Design Review →

Função requerida e falha funcional

A confiabilidade deve ser associada à função requerida, e não apenas ao componente. Um equipamento pode estar energizado e aparentemente íntegro, mas o sistema pode ter perdido a função necessária.

Considere um sistema de alimentação de uma carga crítica. A função pode ser fornecer energia dentro de limites de tensão e frequência, com continuidade compatível com o processo. Uma falha funcional pode ser perda total, mas também transferência acima do tempo permitido, autonomia insuficiente ou operação degradada sem capacidade de suportar uma contingência adicional.

Essa formulação aproxima Reliability by Design de FMEA, FMECA, RCM e análise RAM. A arquitetura passa a ser estudada em relação a funções e consequências, não apenas em relação a listas de equipamentos.

Arquitetura: série, paralelo e redundância

A arquitetura é uma das decisões com maior impacto na confiabilidade do sistema. Em uma cadeia puramente em série, a falha de qualquer elemento necessário pode interromper a função. Em arquiteturas paralelas, redundantes ou reconfiguráveis, a função pode ser preservada mesmo após determinadas falhas.

Em um modelo simplificado com componentes independentes e confiabilidades R1, R2 e R3 em série:

Rs = R1 × R2 × R3

Se cada elemento possui confiabilidade de 0,98 no intervalo analisado, a confiabilidade da cadeia será aproximadamente 0,941. A presença de vários elementos bons não garante que o sistema seja igualmente bom.

Para dois elementos independentes em paralelo, quando basta um funcionar:

Rp = 1 − (1 − R1)(1 − R2)

Com dois elementos de 0,98, o valor teórico sobe para aproximadamente 0,9996. Esse resultado, porém, só é realista se as hipóteses de independência forem plausíveis.

Redundância não elimina falhas de causa comum

Dois equipamentos idênticos podem compartilhar a mesma alimentação, sala, software, firmware, sensor, lógica de controle, rede, procedimento de operação ou erro de projeto. Nesses casos, a redundância física não representa independência funcional completa.

Falhas de causa comum precisam ser consideradas no layout e na arquitetura. Alguns exemplos:

  • dois switches redundantes alimentados pelo mesmo circuito;
  • dois controladores dependentes de um único sensor;
  • duas bombas em paralelo com sucção comum suscetível a bloqueio;
  • equipamentos redundantes instalados no mesmo ambiente sujeito a inundação;
  • duas rotas de comunicação que compartilham a mesma infraestrutura física;
  • UPS redundantes dependentes do mesmo elemento de bypass.

A pergunta de design não é “quantos equipamentos existem?”, mas quantos caminhos realmente independentes existem até a função requerida.

Redundância aparente pode esconder pontos únicos de falha. A análise precisa considerar dependências, causa comum e capacidade real de manter a função em condição degradada.

Aprofunde em Análise RAM →

Mantenabilidade deve ser projetada

A IEC 60300-3-10:2025 reforça a relação entre mantenabilidade, manutenção e demais atributos de dependabilidade ao longo do ciclo de vida. Grande parte do tempo de restabelecimento é influenciada por decisões físicas e informacionais de projeto.

Mantenabilidade envolve, entre outros fatores:

  • acesso seguro aos componentes;
  • espaço para retirada e substituição;
  • modularidade;
  • padronização de interfaces;
  • pontos de teste e medição;
  • identificação e rotulagem;
  • isolamento de energia e seccionamento;
  • possibilidade de manutenção sem interromper funções adjacentes;
  • facilidade de diagnóstico;
  • disponibilidade de procedimentos e dados;
  • necessidade de ferramentas especiais.

Uma válvula instalada sem espaço para manutenção, um painel cuja intervenção exige desligar múltiplas cargas ou um módulo crítico enterrado em uma arquitetura sem diagnóstico são exemplos de dívida de mantenabilidade criada ainda no design.

Testabilidade e diagnóstico

Diagnóstico é parte de Reliability by Design porque reduz o tempo entre a manifestação da falha e a identificação do elemento que precisa de intervenção.

Um sistema bem projetado deve responder, conforme criticidade, a questões como:

  • a falha é detectável automaticamente;
  • existe indicação inequívoca do estado degradado;
  • é possível localizar a falha no nível de intervenção adequado;
  • existem pontos de medição seguros;
  • alarmes distinguem causa de efeito;
  • logs preservam eventos relevantes;
  • a equipe consegue testar a função de proteção ou redundância sem criar risco desnecessário.

Em sistemas digitais, observabilidade, sincronismo temporal, logs, alarmes, diagnósticos internos e telemetria influenciam diretamente a velocidade e a qualidade da recuperação.

FMEA e FMECA durante o projeto

A IEC 60812:2018 estrutura FMEA e FMECA como métodos para identificar como itens ou processos podem falhar, seus efeitos e tratamentos necessários. Durante o projeto, essas análises têm valor especial porque ainda existe liberdade para alterar a arquitetura.

Uma sequência útil é:

  1. Definir função e requisito.
  2. Identificar falha funcional.
  3. Identificar modos de falha plausíveis.
  4. Avaliar efeitos locais e no sistema.
  5. Identificar causas e mecanismos.
  6. Verificar controles existentes.
  7. Avaliar criticidade.
  8. Definir ação de projeto, controle ou verificação.
  9. Registrar evidência de fechamento.

A ação pode resultar em mudança de componente, proteção adicional, diversidade tecnológica, separação física, melhoria de acesso, diagnóstico, alteração de lógica ou simplesmente validação de que o risco residual é aceitável.

Design Review com foco em confiabilidade

Design Review não deve se limitar a verificar consistência gráfica, interferências ou atendimento de escopo. A IEC 61160 trata a revisão de projeto como mecanismo para verificar requisitos de entrada e estimular melhoria do design.

Uma revisão orientada à dependabilidade pode avaliar:

DimensãoPerguntas de revisão
Funçãoos requisitos de serviço estão mensuráveis?
Arquiteturaexistem single points of failure críticos?
Redundânciaos caminhos redundantes são realmente independentes?
Proteçãofalhas são contidas ou propagadas?
Mantenabilidadeintervenção é segura, acessível e executável?
Testabilidadeproteções e redundâncias podem ser verificadas?
Suportesobressalentes, ferramentas e competências são viáveis?
Dadosquais evidências serão coletadas durante operação?
Ciclo de vidaobsolescência e renovação foram consideradas?

A revisão é mais efetiva quando ocorre antes do congelamento da solução. Encontrar um single point of failure em uma arquitetura ainda conceitual custa muito menos do que encontrá-lo durante comissionamento ou operação.

Derating, margens e solicitação dos componentes

Reliability by Design também trata da relação entre solicitação e capacidade. Componentes operando continuamente próximos de limites térmicos, elétricos ou mecânicos podem apresentar comportamento de degradação diferente daquele considerado em condições nominais.

Práticas de projeto podem incluir margens adequadas, controle térmico, análise de carregamento, qualidade de energia, proteção contra surtos, controle de vibração, seleção ambiental e verificação de transientes.

Isso não significa superdimensionar indiscriminadamente. Margem excessiva também pode aumentar CAPEX, espaço, massa, perdas ou complexidade. A decisão deve relacionar condição real de serviço, criticidade, comportamento de falha e custo de ciclo de vida.

Reliability growth e testes acelerados

Projetos novos podem exigir evidência antes de acumular anos de dados de campo. A IEC 62506:2023 apresenta métodos de ensaio acelerado para identificar fraquezas de projeto e obter informações sobre confiabilidade em períodos comprimidos.

O princípio é diferente de simplesmente “testar mais forte”. O ensaio precisa representar mecanismos de falha relevantes e ter relação tecnicamente defensável com o perfil de missão ou ambiente de uso.

Reliability growth ocorre quando falhas e fraquezas identificadas durante desenvolvimento, testes ou operação alimentam ações corretivas de projeto. Testar sem fechar causas e ações apenas produz uma lista de defeitos; o ganho de confiabilidade vem do ciclo detectar → analisar → corrigir → verificar.

Confiabilidade e software

Sistemas atuais combinam hardware, software, redes, dados e lógica. Dependabilidade não pode ser avaliada apenas por taxa de falha física.

Para software e automação, algumas decisões importantes incluem:

  • tratamento de estados inválidos;
  • watchdogs e mecanismos de recuperação;
  • segregação de funções críticas;
  • gestão de configuração;
  • versionamento e rollback;
  • tolerância a perda de comunicação;
  • comportamento em restart;
  • consistência de dados;
  • tratamento de exceções;
  • testes de integração e cenários degradados.

Uma arquitetura com hardware redundante pode continuar vulnerável se ambas as instâncias executarem a mesma lógica defeituosa ou dependerem da mesma configuração incorreta.

Suporte, sobressalentes e obsolescência ainda no design

A confiabilidade percebida pelo usuário depende também da capacidade de recuperar o serviço. Um componente raro, proprietário ou com lead time elevado pode transformar uma falha tecnicamente simples em longa indisponibilidade.

Ainda em projeto, vale avaliar:

  • criticidade dos sobressalentes;
  • tempo de reposição;
  • padronização entre sistemas;
  • possibilidade de substituição equivalente;
  • vida comercial do produto;
  • dependência de licenças, firmware ou serviços externos;
  • documentação necessária para manutenção futura.

Esses fatores conectam Reliability by Design ao Life Cycle Cost e à Gestão de Ativos.

Exemplo: alimentação de um sistema crítico

Considere uma instalação em que determinada carga precisa permanecer disponível durante falha de um alimentador. A primeira solução pode propor duas fontes e dois equipamentos de conversão em paralelo.

Uma revisão de confiabilidade identifica, porém, que ambos os caminhos compartilham o mesmo quadro de distribuição e um único controlador de transferência. O sistema possui redundância aparente, mas dois pontos comuns continuam capazes de interromper a função.

O processo de Reliability by Design poderia gerar ações como:

  • segregação dos caminhos desde a origem;
  • transferência com arquitetura tolerante à falha ou bypass adequado;
  • separação física onde a consequência justificar;
  • instrumentação para verificar estado real de cada caminho;
  • teste periódico da lógica de transferência;
  • acesso de manutenção sem perda simultânea das duas vias;
  • definição de critérios de aceite no comissionamento.

O ganho não está em “duplicar tudo”, mas em identificar onde a função realmente depende de elementos únicos.

Como estruturar um processo de Reliability by Design

Um processo pragmático pode ser organizado em oito etapas:

  1. Definir funções e níveis de serviço. Registrar o que precisa ser preservado e em quais condições.
  2. Especificar requisitos de dependabilidade. Converter expectativas em requisitos verificáveis.
  3. Modelar a arquitetura funcional. Identificar caminhos, dependências e pontos únicos de falha.
  4. Analisar modos e consequências de falha. Aplicar FMEA/FMECA, RBD, FTA ou outras técnicas conforme necessidade.
  5. Projetar mantenabilidade, testabilidade e suporte. Garantir que recuperação seja tecnicamente executável.
  6. Revisar decisões críticas de design. Usar Design Review com critérios explícitos de confiabilidade.
  7. Verificar e demonstrar. Testes, inspeções, simulações, FAT/SAT e comissionamento precisam produzir evidência.
  8. Retroalimentar com dados de campo. Falhas, intervenções e desempenho real devem alimentar novos projetos e revisões.

Indicadores de projeto para confiabilidade

Nem todo indicador precisa esperar operação. Durante desenvolvimento podem ser acompanhados, por exemplo:

  • requisitos de dependabilidade definidos e verificados;
  • single points of failure identificados e tratados;
  • ações de FMEA/FMECA abertas e encerradas;
  • cobertura de modos de falha críticos por controles;
  • requisitos de mantenabilidade demonstrados;
  • testes de cenários degradados executados;
  • riscos residuais formalmente aceitos;
  • pendências de design com impacto na operação.

Depois da entrada em serviço, indicadores reais como disponibilidade, MTBF, MTTR, falhas recorrentes e indisponibilidade por causa podem validar as hipóteses de projeto.

Quando Reliability by Design agrega mais valor

A abordagem tende a produzir maior retorno em sistemas críticos, arquiteturas complexas, projetos com alta integração, instalações com restrições severas de parada, ativos de longa vida e soluções em que a manutenção futura será cara ou difícil.

Também é particularmente útil em projetos brownfield, porque novas soluções precisam coexistir com limitações, interfaces e dependências de sistemas existentes.

A melhor oportunidade de corrigir uma fragilidade é antes que ela seja construída. Reliability by Design transforma confiabilidade de um resultado esperado em requisito, decisão de engenharia e evidência verificável.

Projetar para confiabilidade reduz a necessidade de corrigir fragilidades em operação. Quando o sistema já existe, a próxima etapa é diagnosticar desempenho, causas, dependências e riscos residuais.

Engenharia de Confiabilidade e Disponibilidade →

Referências técnicas

[1] IEC. IEC 60300-1:2024 — Dependability management — Part 1: Managing dependability. Geneva: IEC, 2024.

[2] IEC. IEC 60300-3-4:2022 — Dependability management — Part 3-4: Application guide — Specification of dependability requirements. Geneva: IEC, 2022.

[3] IEC. IEC 61160:2005 — Design review. Geneva: IEC, 2005.

[4] IEC. IEC 62506:2023 — Methods for product accelerated testing. Geneva: IEC, 2023.

[5] IEC. IEC 60812:2018 — Failure modes and effects analysis (FMEA and FMECA). Geneva: IEC, 2018.

[6] IEC. IEC 60300-3-10:2025 — Dependability management — Part 3-10: Application guide — Maintainability and maintenance. Geneva: IEC, 2025.

Perguntas frequentes
O que é Reliability by Design?

É a abordagem de incorporar requisitos de confiabilidade, disponibilidade, manutenibilidade e suporte desde as decisões de projeto, em vez de avaliar esses atributos apenas após a entrada em operação.

Reliability by Design é o mesmo que redundância?

Não. Redundância é apenas uma possível decisão de arquitetura. Reliability by Design também trata requisitos, falhas de causa comum, mantenabilidade, testabilidade, margens, suporte, software, verificação e ciclo de vida.

Qual a diferença entre Reliability by Design e FMEA?

FMEA é uma técnica de análise de modos e efeitos de falha. Reliability by Design é uma abordagem mais ampla de engenharia que pode utilizar FMEA, FMECA, RBD, FTA, Design Review e outras técnicas.

Em que fase do projeto a confiabilidade deve ser analisada?

Desde a definição de requisitos e arquitetura. Quanto mais tarde uma fragilidade é identificada, maior tende a ser o custo de corrigir layout, interfaces, redundância, acessibilidade ou estratégia de suporte.

Como projetar para manutenibilidade?

Definindo requisitos de acesso, isolamento, modularidade, diagnóstico, espaço de intervenção, pontos de teste, documentação, ferramentas e tempo de restabelecimento ainda durante o projeto.

Reliability by Design se aplica a software e automação?

Sim. Dependabilidade de sistemas modernos também depende de software, comunicação, dados, configuração, tratamento de estados degradados, recuperação e observabilidade.

Materiais técnicos complementares

Soluções relacionadas

Serviços de engenharia relacionados

Conteúdos técnicos correlatos

Guias, frameworks e referenciais