Reliability by Design aplicado a sistemas de ingeniería: requisitos, arquitectura, redundancia, causa común, mantenibilidad, testabilidad, FMEA, Design Review y verificación.
¡Descúbrelo!
Reliability by Design es la aplicación sistemática de requisitos, análisis y decisiones de ingeniería para que la confiabilidad, la disponibilidad, la mantenibilidad y el soporte no se evalúen solo después de que el sistema entre en operación. La lógica es simple: las características de dependability quedan fuertemente determinadas durante la definición de requisitos, arquitectura, especificación, selección de componentes, interfaces, accesibilidad, redundancia, protección, pruebas y preparación para mantenimiento.
Cuando estos atributos se incorporan tarde al proyecto, la organización tiende a compensar las limitaciones de diseño con inventario, inspecciones excesivas, contingencias operativas, intervenciones difíciles o redundancias añadidas posteriormente. El resultado puede ser técnicamente funcional en la entrega, pero costoso, frágil o difícil de sostener a lo largo del ciclo de vida.
Diseñar para la confiabilidad no significa buscar cero fallas ni añadir redundancia indiscriminadamente. Significa transformar necesidades de servicio y consecuencias de falla en requisitos verificables y tomar decisiones conscientes sobre arquitectura, componentes, márgenes, mantenibilidad, diagnóstico, soporte y evidencias de desempeño.
¿Qué es Reliability by Design?
Reliability by Design, frecuentemente asociado a Design for Reliability — DfR, es un enfoque de ingeniería en el que los atributos de dependability se tratan como requisitos de diseño desde las etapas iniciales. IEC 60300-1:2024 estructura la dependability como la capacidad de un sistema, producto o servicio para desempeñarse según lo requerido cuando se requiere, considerando el ciclo de vida y las interfaces entre aspectos técnicos, financieros y de gestión.
En la práctica, Reliability by Design conecta cuatro preguntas:
- qué función debe desempeñar el sistema y en qué condiciones;
- durante cuánto tiempo, o con qué nivel de disponibilidad, debe estar accesible esa función;
- cómo puede fallar el sistema y qué consecuencias son aceptables;
- cómo detectar, aislar, reparar, recuperar y sostener el sistema cuando exista degradación o falla.
La respuesta no pertenece a una sola disciplina. Eléctrica, automatización, telecomunicaciones, mecánica, civil, software, operación, mantenimiento, seguridad y supply chain pueden participar en la dependability del mismo sistema.
El requisito de confiabilidad debe nacer antes que la solución
Un error frecuente es definir primero la arquitectura y preguntar después qué confiabilidad ofrece. El camino más robusto es invertir la lógica: definir la necesidad de servicio, establecer criterios y solo entonces seleccionar una arquitectura capaz de cumplirlos.
IEC 60300-3-4:2022 orienta la especificación de requisitos cuantitativos y cualitativos de confiabilidad, mantenibilidad, supportability y disponibilidad. Esto ayuda a distinguir metas vagas de requisitos verificables.
“Sistema altamente confiable” no es un requisito técnico. Formulaciones mejores pueden incluir:
- disponibilidad operacional mínima durante un período definido;
- probabilidad de éxito durante una misión;
- tiempo máximo de restablecimiento para una determinada clase de falla;
- tolerancia a falla simple en funciones críticas;
- límite de pérdida de capacidad en condición degradada;
- necesidad de prueba automática, diagnóstico o indicación de falla;
- accesibilidad y tiempo de sustitución de módulos críticos.
El requisito debe incluir el contexto operacional. Temperatura, polvo, humedad, vibración, régimen de carga, maniobras, ciclos, calidad de energía, perfil de tráfico, agresividad ambiental y capacidad del equipo de mantenimiento modifican el desempeño esperado.
La confiabilidad debe especificarse antes de poder verificarse. Requisitos vagos como “alta disponibilidad” no orientan arquitectura, pruebas ni aceptación técnica.
Función requerida y falla funcional
La confiabilidad debe asociarse a la función requerida, y no solo al componente. Un equipo puede estar energizado y aparentemente íntegro, pero el sistema puede haber perdido la función necesaria.
Considere un sistema de alimentación de una carga crítica. La función puede ser suministrar energía dentro de límites de tensión y frecuencia, con continuidad compatible con el proceso. Una falla funcional puede ser una pérdida total, pero también una transferencia por encima del tiempo permitido, autonomía insuficiente u operación degradada sin capacidad para soportar una contingencia adicional.
Esta formulación aproxima Reliability by Design a FMEA, FMECA, RCM y análisis RAM. La arquitectura pasa a estudiarse en relación con funciones y consecuencias, y no solo con listas de equipos.
Arquitectura: serie, paralelo y redundancia
La arquitectura es una de las decisiones con mayor impacto en la confiabilidad del sistema. En una cadena puramente en serie, la falla de cualquier elemento necesario puede interrumpir la función. En arquitecturas paralelas, redundantes o reconfigurables, la función puede preservarse incluso después de determinadas fallas.
En un modelo simplificado con componentes independientes y confiabilidades R1, R2 y R3 en serie:
Rs = R1 × R2 × R3
Si cada elemento tiene una confiabilidad de 0,98 en el intervalo analizado, la confiabilidad de la cadena será aproximadamente 0,941. La presencia de varios elementos buenos no garantiza que el sistema sea igualmente bueno.
Para dos elementos independientes en paralelo, cuando basta con que uno funcione:
Rp = 1 − (1 − R1)(1 − R2)
Con dos elementos de 0,98, el valor teórico sube a aproximadamente 0,9996. Sin embargo, este resultado solo es realista si las hipótesis de independencia son plausibles.
La redundancia no elimina las fallas de causa común
Dos equipos idénticos pueden compartir la misma alimentación, sala, software, firmware, sensor, lógica de control, red, procedimiento operativo o error de diseño. En estos casos, la redundancia física no representa independencia funcional completa.
Las fallas de causa común deben considerarse en el layout y en la arquitectura. Algunos ejemplos:
- dos switches redundantes alimentados por el mismo circuito;
- dos controladores dependientes de un único sensor;
- dos bombas en paralelo con succión común susceptible a bloqueo;
- equipos redundantes instalados en el mismo ambiente sujeto a inundación;
- dos rutas de comunicación que comparten la misma infraestructura física;
- UPS redundantes dependientes del mismo elemento de bypass.
La pregunta de diseño no es “¿cuántos equipos existen?”, sino cuántos caminos realmente independientes existen hasta la función requerida.
La redundancia aparente puede ocultar puntos únicos de falla. El análisis debe considerar dependencias, causa común y capacidad real de mantener la función en condición degradada.
La mantenibilidad debe diseñarse
IEC 60300-3-10:2025 refuerza la relación entre mantenibilidad, mantenimiento y los demás atributos de dependability a lo largo del ciclo de vida. Gran parte del tiempo de restablecimiento está influido por decisiones físicas e informacionales de diseño.
La mantenibilidad implica, entre otros factores:
- acceso seguro a los componentes;
- espacio para retirada y sustitución;
- modularidad;
- estandarización de interfaces;
- puntos de prueba y medición;
- identificación y etiquetado;
- aislamiento de energía y seccionamiento;
- posibilidad de mantenimiento sin interrumpir funciones adyacentes;
- facilidad de diagnóstico;
- disponibilidad de procedimientos y datos;
- necesidad de herramientas especiales.
Una válvula instalada sin espacio para mantenimiento, un panel cuya intervención exige desconectar múltiples cargas o un módulo crítico enterrado en una arquitectura sin diagnóstico son ejemplos de deuda de mantenibilidad creada todavía en el diseño.
Testabilidad y diagnóstico
El diagnóstico forma parte de Reliability by Design porque reduce el tiempo entre la manifestación de la falla y la identificación del elemento que requiere intervención.
Un sistema bien diseñado debe responder, de acuerdo con su criticidad, a preguntas como:
- si la falla es detectable automáticamente;
- si existe indicación inequívoca del estado degradado;
- si es posible localizar la falla en el nivel de intervención adecuado;
- si existen puntos de medición seguros;
- si las alarmas distinguen causa de efecto;
- si los logs preservan eventos relevantes;
- si el equipo puede probar la función de protección o redundancia sin crear riesgo innecesario.
En sistemas digitales, observabilidad, sincronismo temporal, logs, alarmas, diagnósticos internos y telemetría influyen directamente en la velocidad y la calidad de la recuperación.
FMEA y FMECA durante el diseño
IEC 60812:2018 estructura FMEA y FMECA como métodos para identificar cómo pueden fallar elementos o procesos, sus efectos y los tratamientos necesarios. Durante el diseño, estos análisis tienen especial valor porque aún existe libertad para modificar la arquitectura.
Una secuencia útil es:
- Definir función y requisito.
- Identificar la falla funcional.
- Identificar modos de falla plausibles.
- Evaluar efectos locales y sobre el sistema.
- Identificar causas y mecanismos.
- Verificar controles existentes.
- Evaluar criticidad.
- Definir acción de diseño, control o verificación.
- Registrar evidencia de cierre.
La acción puede resultar en cambio de componente, protección adicional, diversidad tecnológica, separación física, mejora de acceso, diagnóstico, alteración de lógica o simplemente validación de que el riesgo residual es aceptable.
Design Review con foco en confiabilidad
Design Review no debe limitarse a verificar consistencia gráfica, interferencias o cumplimiento del alcance. IEC 61160 trata la revisión de diseño como un mecanismo para verificar requisitos de entrada y estimular la mejora del diseño.
Una revisión orientada a dependability puede evaluar:
| Dimensión | Preguntas de revisión |
| Función | ¿los requisitos de servicio son mensurables? |
| Arquitectura | ¿existen single points of failure críticos? |
| Redundancia | ¿los caminos redundantes son realmente independientes? |
| Protección | ¿las fallas se contienen o se propagan? |
| Mantenibilidad | ¿la intervención es segura, accesible y ejecutable? |
| Testabilidad | ¿las protecciones y redundancias pueden verificarse? |
| Soporte | ¿son viables los repuestos, herramientas y competencias? |
| Datos | ¿qué evidencias se recopilarán durante la operación? |
| Ciclo de vida | ¿se consideraron obsolescencia y renovación? |
La revisión es más eficaz cuando ocurre antes del congelamiento de la solución. Encontrar un single point of failure en una arquitectura todavía conceptual cuesta mucho menos que encontrarlo durante commissioning u operación.
Derating, márgenes y solicitación de los componentes
Reliability by Design también trata la relación entre solicitación y capacidad. Componentes que operan continuamente cerca de límites térmicos, eléctricos o mecánicos pueden presentar un comportamiento de degradación diferente del considerado en condiciones nominales.
Las prácticas de diseño pueden incluir márgenes adecuados, gestión térmica, análisis de carga, calidad de energía, protección contra sobretensiones, control de vibración, selección ambiental y verificación de transitorios.
Esto no significa sobredimensionar indiscriminadamente. Los márgenes excesivos también pueden aumentar CAPEX, espacio, masa, pérdidas o complejidad. La decisión debe relacionar condición real de servicio, criticidad, comportamiento de falla y costo de ciclo de vida.
Reliability growth y pruebas aceleradas
Los proyectos nuevos pueden exigir evidencia antes de acumular años de datos de campo. IEC 62506:2023 presenta métodos de ensayo acelerado para identificar debilidades de diseño y obtener información de confiabilidad en períodos comprimidos.
El principio es diferente de simplemente “probar más fuerte”. El ensayo debe representar mecanismos de falla relevantes y tener una relación técnicamente defendible con el perfil de misión o ambiente de uso.
Reliability growth ocurre cuando las fallas y debilidades identificadas durante desarrollo, pruebas u operación alimentan acciones correctivas de diseño. Probar sin cerrar causas y acciones solo produce una lista de defectos; la mejora de confiabilidad proviene del ciclo detectar → analizar → corregir → verificar.
Confiabilidad y software
Los sistemas actuales combinan hardware, software, redes, datos y lógica. La dependability no puede evaluarse solo mediante tasa de falla física.
Para software y automatización, algunas decisiones importantes incluyen:
- tratamiento de estados inválidos;
- watchdogs y mecanismos de recuperación;
- segregación de funciones críticas;
- gestión de configuración;
- versionado y rollback;
- tolerancia a pérdida de comunicación;
- comportamiento en restart;
- consistencia de datos;
- tratamiento de excepciones;
- pruebas de integración y escenarios degradados.
Una arquitectura con hardware redundante puede continuar vulnerable si ambas instancias ejecutan la misma lógica defectuosa o dependen de la misma configuración incorrecta.
Soporte, repuestos y obsolescencia desde el diseño
La confiabilidad percibida por el usuario también depende de la capacidad para recuperar el servicio. Un componente raro, propietario o con lead time elevado puede transformar una falla técnicamente simple en una indisponibilidad prolongada.
Durante el diseño, conviene evaluar:
- criticidad de los repuestos;
- tiempo de reposición;
- estandarización entre sistemas;
- posibilidad de sustitución equivalente;
- vida comercial del producto;
- dependencia de licencias, firmware o servicios externos;
- documentación necesaria para mantenimiento futuro.
Estos factores conectan Reliability by Design con Life Cycle Cost y Asset Management.
Ejemplo: alimentación de un sistema crítico
Considere una instalación en la que una determinada carga necesita permanecer disponible durante la falla de un alimentador. La primera solución puede proponer dos fuentes y dos equipos de conversión en paralelo.
Sin embargo, una revisión de confiabilidad identifica que ambos caminos comparten el mismo tablero de distribución y un único controlador de transferencia. El sistema posee redundancia aparente, pero dos puntos comunes siguen siendo capaces de interrumpir la función.
El proceso de Reliability by Design podría generar acciones como:
- segregación de caminos desde el origen;
- transferencia con arquitectura tolerante a falla o bypass adecuado;
- separación física cuando la consecuencia lo justifique;
- instrumentación para verificar el estado real de cada camino;
- prueba periódica de la lógica de transferencia;
- acceso de mantenimiento sin pérdida simultánea de las dos vías;
- definición de criterios de aceptación en commissioning.
La mejora no está en “duplicarlo todo”, sino en identificar dónde la función realmente depende de elementos únicos.
Cómo estructurar un proceso de Reliability by Design
Un proceso pragmático puede organizarse en ocho etapas:
- Definir funciones y niveles de servicio. Registrar qué debe preservarse y bajo qué condiciones.
- Especificar requisitos de dependability. Convertir expectativas en requisitos verificables.
- Modelar la arquitectura funcional. Identificar caminos, dependencias y puntos únicos de falla.
- Analizar modos y consecuencias de falla. Aplicar FMEA/FMECA, RBD, FTA u otras técnicas según necesidad.
- Diseñar mantenibilidad, testabilidad y soporte. Garantizar que la recuperación sea técnicamente ejecutable.
- Revisar decisiones críticas de diseño. Utilizar Design Review con criterios explícitos de confiabilidad.
- Verificar y demostrar. Pruebas, inspecciones, simulaciones, FAT/SAT y commissioning deben producir evidencia.
- Retroalimentar con datos de campo. Fallas, intervenciones y desempeño real deben alimentar nuevos proyectos y revisiones.
Indicadores de diseño para confiabilidad
No todos los indicadores necesitan esperar la operación. Durante el desarrollo pueden acompañarse, por ejemplo:
- requisitos de dependability definidos y verificados;
- single points of failure identificados y tratados;
- acciones de FMEA/FMECA abiertas y cerradas;
- cobertura de modos de falla críticos mediante controles;
- requisitos de mantenibilidad demostrados;
- pruebas de escenarios degradados ejecutadas;
- riesgos residuales formalmente aceptados;
- pendencias de diseño con impacto en la operación.
Después de la entrada en servicio, indicadores reales como disponibilidad, MTBF, MTTR, fallas recurrentes e indisponibilidad por causa pueden validar las hipótesis de diseño.
Cuándo Reliability by Design agrega más valor
El enfoque tiende a producir mayor retorno en sistemas críticos, arquitecturas complejas, proyectos con alta integración, instalaciones con restricciones severas de parada, activos de larga vida y soluciones en las que el mantenimiento futuro será costoso o difícil.
También es particularmente útil en proyectos brownfield, porque las nuevas soluciones deben coexistir con limitaciones, interfaces y dependencias de sistemas existentes.
La mejor oportunidad para corregir una fragilidad es antes de que se construya. Reliability by Design transforma la confiabilidad de un resultado esperado en requisito, decisión de ingeniería y evidencia verificable.
Diseñar para la confiabilidad reduce la necesidad de corregir fragilidades durante la operación. Cuando el sistema ya existe, el siguiente paso es diagnosticar desempeño, causas, dependencias y riesgos residuales.
Referencias 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.
Preguntas frecuentes
Es el enfoque de incorporar requisitos de confiabilidad, disponibilidad, mantenibilidad y soporte desde las decisiones de diseño, en lugar de evaluar estos atributos solo después de la entrada en operación.
No. La redundancia es solo una posible decisión de arquitectura. Reliability by Design también trata requisitos, fallas de causa común, mantenibilidad, testabilidad, márgenes, soporte, software, verificación y ciclo de vida.
FMEA es una técnica de análisis de modos y efectos de falla. Reliability by Design es un enfoque de ingeniería más amplio que puede utilizar FMEA, FMECA, RBD, FTA, Design Review y otras técnicas.
Desde la definición de requisitos y arquitectura. Cuanto más tarde se identifica una fragilidad, mayor tiende a ser el costo de corregir layout, interfaces, redundancia, accesibilidad o estrategia de soporte.
Definiendo requisitos de acceso, aislamiento, modularidad, diagnóstico, espacio de intervención, puntos de prueba, documentación, herramientas y tiempo de restablecimiento durante el diseño.
Sí. La dependability de sistemas modernos también depende de software, comunicaciones, datos, configuración, tratamiento de estados degradados, recuperación y observabilidad.
Materiales técnicos complementarios
Soluciones relacionadas
- Gestión de Requisitos, Evidencias y Criterios de Aceptación
- Gestión del Conocimiento Técnico y Lecciones Aprendidas
- Aplicaciones de Campo, Inspección y Recolección de Datos Técnicos
Servicios de ingeniería relacionados
- Design Review en Proyectos de Ingeniería
- Ingeniería de Confiabilidad y Disponibilidad
- Ingeniería de Mantenimiento
Contenidos técnicos correlacionados
- Ingeniería de Confiabilidad
- Análisis RAM
- FMEA en Ingeniería
- FMECA
- Design Review en Proyectos de Ingeniería
- Life Cycle Cost — LCC
Guías, frameworks y referencias
