Guía de desarrollo de hardware ISO 26262-5: Requisitos, métricas y pruebas

• AutorJohnny Liu (Director Ejecutivo de Dowway Vehicle)
• Fecha7 de julio de 2026
• CategoríaIngeniería de seguridad funcional y hardware en el sector automotriz.

Los coches modernos están repletos de componentes electrónicos complejos. A medida que desarrollamos vehículos más inteligentes, las placas de circuitos y los chips de silicio que contienen deben ser extremadamente fiables.

He pasado años trabajando en hardware de vehículos. Sé lo difícil que puede ser cumplir con las normas de seguridad funcional. Esta guía le ayudará a comprenderlo mejor. ISO 26262-5 (desarrollo a nivel de hardware) Utilizaremos pasos claros y prácticos. Cubriremos todo, desde los requisitos hasta las métricas como SPFM, LFM y PMHF.

1. Las tres actividades básicas de seguridad del hardware

Para garantizar la seguridad de los sistemas automotrices, no podemos simplemente esperar que el hardware funcione. Debemos diseñarlo para que pueda soportar fallos.

La norma ISO 26262-5 describe tres actividades principales que debe realizar:

1. Incorpore el concepto de seguridad técnica en el hardware.
2. Analizar posibles fallos de hardware y determinar sus efectos.
3. Colaborar estrechamente con el equipo de software.

La lógica detrás de la cláusula 8 y la cláusula 9

La norma utiliza dos cláusulas distintas para medir la seguridad de su hardware:

• Cláusula 8 (Métricas de arquitectura de hardware)Esta cláusula utiliza dos porcentajes —la métrica de fallo de punto único (SPFM) y la métrica de fallo latente (LFM)— para medir la eficacia con la que el diseño del hardware y los mecanismos de seguridad gestionan los fallos físicos aleatorios.
• Cláusula 9 (Evaluación de fallos aleatorios de hardware)Esta cláusula analiza el riesgo general. Utiliza un cálculo de probabilidad matemático complejo (PMHF) o un análisis de conjuntos de corte para comprobar si el riesgo de incumplir un objetivo de seguridad es suficientemente bajo.

2. Configuración de los requisitos de seguridad del hardware (HSR)

Su Requisitos de seguridad del hardware (HSR) Debe derivarse directamente de los Requisitos Técnicos de Seguridad (TSR) a nivel de sistema. También debe redactar un documento detallado. Interfaz hardware-software (HSI) Especificación para mostrar cómo interactúan las partes físicas y el código.

Su informe de seguridad sanitaria debe abarcar cinco áreas clave:

1) Control de fallas internas

Sus requisitos deben especificar cómo gestionar los fallos internos de sus unidades de hardware. Esto incluye métodos para detectar fallos temporales (fallos transitorios) mediante herramientas como temporizadores y sistemas de vigilancia.

2) Resistencia a fallos externos

El hardware debe soportar fallos externos a su placa. Por ejemplo, si falla una unidad de control electrónico (ECU) externa, las entradas de su ECU deben gestionar problemas como circuitos abiertos o cortocircuitos en la línea de alimentación (KL30).

3) Emparejamiento entre unidades

Asegúrese de que sus requisitos de seguridad coincidan y funcionen correctamente con los requisitos de seguridad de las unidades de hardware vecinas en el automóvil.

4) Detección y señalización de fallos

Tu diseño debe detectar y reportar fallas rápidamente. Debes redactar requisitos para detectar fallas físicas comunes, incluyendo:

• pines abiertos
• Corto al suelo
• Cortocircuito a potencia

5) Reglas de verificación del diseño

La HSR no debe obligarte a usar un mecanismo de seguridad específico. En cambio, debe definir las reglas que usarás para verificar el diseño posteriormente. Estas reglas incluyen:

• límites ambientales: Temperatura, vibración e interferencia electromagnética (EMI).
• Condiciones de funcionamiento: Rangos de voltaje de la fuente de alimentación y uso previsto durante su vida útil (perfiles de misión).
• Reglas específicas de los componentes: Requisitos para microchips o controladores de potencia específicos.

3. Diseño de hardware: De la arquitectura a los esquemas

El diseño de hardware abarca desde la arquitectura general hasta los esquemas de circuitos propiamente dichos.

Arquitectura de gran envergadura

Tu arquitectura muestra todas tus unidades de hardware y cómo se conectan entre sí.

• Herencia ASILCada unidad de hardware debe cumplir con los requisitos de seguridad del nivel más alto de integridad de seguridad automotriz (ASIL) que se le haya asignado.
• La trazabilidad es crucial.Debe poder rastrear sus requisitos desde el HSR de alto nivel hasta el bloque de circuito funcional más pequeño de su placa. Esta trazabilidad bidireccional es la regla fundamental tanto de ISO 26262 como de ASPICE.
• Manténgalo simplePara evitar errores de diseño, utilice un diseño modular, mantenga los bloques de tamaño razonable y evite la complejidad innecesaria.
• Estrés ambientalDebes tener en cuenta factores del mundo real como el calor, la vibración, la humedad, el polvo y el ruido electromagnético (EMI) proveniente de otros componentes del vehículo. Estas consideraciones deben incluirse en las pruebas de tu Plan de Verificación de Diseño (DVP) (pruebas de compatibilidad electromagnética, eléctricas y ambientales del ciclo de vida).

Diseño esquemático detallado

Cuando empieces a dibujar líneas en tu esquema, sigue estas reglas:

1. Aprende del pasado.Siga la cultura de seguridad de su empresa y utilice las lecciones aprendidas de proyectos anteriores (consulte la norma ISO 26262-2:2018, apartado 5.4.7).
2. Prevenir el estrés físico excesivoDiseñe sus circuitos para que resistan el ruido eléctrico, el calor y la humedad.
3. Manténgase dentro de los límitesAsegúrese de que todas las piezas funcionen dentro de sus límites ambientales especificados.
4. Utilice métodos robustosUtilice prácticas de diseño de gestión de calidad (GC) fiables. Estas incluyen la selección conservadora de componentes, la reducción de la capacidad de los componentes (hacer funcionar las piezas por debajo de sus límites máximos) y el análisis de circuitos en el peor de los casos (ACCC).

4. Análisis de seguridad del hardware: Clasificación de fallos

Para encontrar dónde podría fallar su hardware, debe realizar un análisis de seguridad. Este análisis se basa en ISO 26262-9:2011 Cláusula 8.

Este análisis te ayuda a refinar tu diseño desde el principio y a verificar tu trabajo más adelante. Es obligatorio para los sistemas dirigidos a ASIL (B), C o D.

Su análisis de seguridad debe considerar tres tipos de fallas:

• Fallos seguros: Fallos que no violan directamente sus objetivos de seguridad.
• Fallas de punto único (SPF) / Fallas residuales (RF).
• Fallas multipunto (MPF) (incluyendo fallas percibidas, detectadas y latentes).

En la mayoría de los proyectos reales, puede limitar su análisis multipunto a fallas de doble punto (Dos fallos independientes que ocurren simultáneamente). No es necesario analizar todas las combinaciones posibles de fallos de dos componentes. En su lugar, concéntrese en las combinaciones en las que un fallo afecta a un componente de hardware principal y el segundo fallo interrumpe el mecanismo de seguridad diseñado para proteger dicho componente.

Fallas de punto único (SPF)

Un SPF es un fallo físico en un único componente de hardware que no es detectado por ningún mecanismo de seguridad y que provoca directamente que el sistema incumpla un objetivo de seguridad.

Para demostrar que ha mitigado los SPF para sistemas ASIL (B), C o D, debe demostrar:

• A) Mecanismos de seguridad fiables: Tienes mecanismos de seguridad que pueden mantener el sistema seguro o cambiarlo a un estado seguro. Esto debe ocurrir dentro de los sistemas. Intervalo de tiempo tolerante a fallas (FTTI).
• B) Alta cobertura diagnósticaDebes calcular cuántas fallas residuales pueden detectar tus diagnósticos.

Reglas clave de diseño para SPF:

• La regla FTTI: Si su prueba de diagnóstico tarda demasiado en ejecutarse, o si el mecanismo de seguridad tarda demasiado en responder, y el tiempo total es mayor que su FTTI, el mecanismo no es válido.
• Comprobaciones de encendidoSi la falla solo se puede detectar al arrancar el vehículo, debe realizar las autocomprobaciones inmediatamente después de encenderlo, antes de comenzar a conducir.
• Herramientas analíticasUtilice el Análisis de Modos y Efectos de Fallo (AMFE) o el Análisis de Árbol de Fallos (ATF) para comprobar sus cálculos.
• Nivel de evaluaciónDependiendo de los componentes, puede analizar el chip en su conjunto o examinar detenidamente los modos de fallo de cada pin individual.

Fallos latentes

Una falla latente es una falla en múltiples puntos que no es detectada por los mecanismos de seguridad y que el conductor no puede percibir. Con el tiempo, estas fallas ocultas se acumulan y pueden provocar fallas repentinas del sistema cuando se rompe una segunda pieza.

Para demostrar que se ha protegido contra fallas latentes, debe demostrar:

• A) Notificación al conductorEl sistema puede detectar la primera falla y advertir al conductor dentro de un plazo aceptable antes de que ocurra una segunda falla.
• B) Cobertura medidaDebe evaluar y calcular su cobertura de diagnóstico para estas fallas ocultas.

Reglas clave de diseño para fallas latentes:

• Si el intervalo entre las pruebas de diagnóstico y el tiempo de respuesta es mayor que el intervalo de tiempo definido para la detección de fallos en múltiples puntos, el fallo se considera no detectado (latente).
• Utilice FMEA cuantitativo o FTA para construir su modelo matemático.

Verificación: La relación entre 3a/3b y 1a/1b

Durante la verificación del diseño, se utilizan métodos estándar. 3a y 3b Actúan como controles específicos sobre los principios de diseño ambiental y robusto. Úselos para complementar y reforzar sus métodos de verificación básicos. 1a y 1b.

5. Métricas de arquitectura de hardware y tasas de fallos

Para demostrar a los auditores externos que su diseño es seguro, debe calcular sus métricas arquitectónicas.

Dónde encontrar datos de tasa de fallos (FIT)

No puedes inventarte las tasas de fallos. Debes obtener tus datos de Fallo en el Tiempo (FIT) de una de estas tres fuentes:

Fuente 1: Estándares reconocidos de la industria

Esta es la forma más común de encontrar las tasas de fallas de los componentes. Puede utilizar:

• SN 29500 (Estándar de Siemens, ampliamente utilizado en la industria automotriz).
• IEC/TR 62380 o IEC 61709.
• Aviso 2 del MIL HDBK 217 F o RIAC HDBK 217.
• UTE C80-811.
• NPRD95.
• EN 50129:2003 Anexo C o IEC 62061:2005 Anexo D.
• RIAC FMD97 o MIL HDBK 338.

Fuente 2: Datos de retorno de campo

Puedes utilizar datos reales de vehículos en circulación, pero tus datos deben tener un alto nivel de confianza.

Fuente 3: Juicio experto estructurado

Si no existen datos, puede utilizar evaluaciones estructuradas de expertos en ingeniería. Debe anotar las razones y los criterios exactos que utilizaron para fundamentar su juicio.

Objetivos métricos para los niveles ASIL

Para superar la auditoría, su diseño debe cumplir los siguientes objetivos mínimos:

Métrico	ASIL B	ASIL C	ASIL D
Métrica de falla de punto único (SPFM)	$\ge 90\%$	$\ge 97\%$	$\ge 99\%$
Métrica de fallas latentes (LFM)	$\ge 60\%$	$\ge 80\%$	$\ge 90\%$
Probabilidad de fallo aleatorio del hardware (PMHF)	$<10⁻⁷ h⁻¹$ (100 FIT)	$<10⁻⁷ h⁻¹$ (100 FIT)	$<10⁻⁸ h⁻¹$ (10 FIT)

6. Cerrando el ciclo: Pruebas de seguridad del hardware

No puedes basarte únicamente en papeleo y cálculos. Debes probar físicamente tu hardware para detectar cualquier fallo de diseño restante.

Para verificar sus mecanismos de seguridad, escriba casos de prueba basados ​​en estos tres métodos de prueba:

A. Pruebas funcionales

Esta prueba demuestra que tu placa funciona correctamente en condiciones normales. Proporcionas entradas normales y compruebas si las salidas coinciden con tus especificaciones. Si algo no funciona correctamente, debes analizar la causa.

B. Pruebas de inyección de fallos

Esta prueba demuestra que sus mecanismos de seguridad funcionan correctamente cuando surgen problemas. Se daña físicamente la placa o se simula una falla (como un cortocircuito entre un pin y tierra) y se observa la reacción del sistema. Esta es la mejor manera de verificar los tiempos de respuesta de seguridad.

C. Pruebas eléctricas

Esta prueba verifica el diseño en todo su rango de voltaje de funcionamiento. Se somete la placa a voltajes altos, bajos y picos de voltaje repentinos para garantizar su estabilidad.

Pruebas de estrés ambiental

También debes probar qué tan bien soporta el hardware el estrés físico externo. Esto incluye someter la placa a pruebas de alta vibración, pruebas de ciclos de temperatura (desde temperaturas extremadamente bajas hasta altas) y pruebas de ruido electromagnético (CEM) intenso.

Reflexiones finales

La seguridad funcional es un proceso iterativo. Se comienza con los requisitos, se diseñan los circuitos, se analizan mediante AMFE y cálculos, y luego se verifica todo con pruebas físicas. Si las pruebas revelan debilidades, se revisa el diseño, se actualiza y se vuelven a realizar las pruebas. Siguiendo este ciclo, construimos vehículos verdaderamente seguros y robustos.

Preguntas frecuentes

P1: ¿Qué sucede si la prueba de diagnóstico y la respuesta de seguridad tardan más que el intervalo de tiempo tolerante a fallos (FTTI)?

Respuesta breve: El mecanismo de seguridad no es válido porque no puede proteger el sistema a tiempo.

DetallesSi se produce un fallo y el diagnóstico tarda demasiado en detectarlo, el sistema podría colapsar o comportarse de forma peligrosa antes de que se active el mecanismo de seguridad. El tiempo total de reacción —desde el momento en que se produce el fallo físico hasta que el sistema alcanza un estado seguro— siempre debe ser inferior al FTTI.

P2: ¿Cuál es la relación entre los métodos de verificación 3a/3b y 1a/1b en la norma ISO 26262-5?

Respuesta breveLos métodos 3a y 3b son comprobaciones específicas y dirigidas que se utilizan para respaldar y reforzar las comprobaciones de diseño básicas 1a y 1b.

DetallesLos métodos 1a (verificación de límites ambientales) y 1b (uso de reglas de diseño como la reducción de potencia y el análisis de capacidad de carga) constituyen las prácticas de diseño fundamentales. Los métodos 3a y 3b actúan como una segunda capa de verificación. Se centran en puntos de falla física específicos y condiciones ambientales para garantizar que no se haya omitido nada en el diseño inicial.

P3: ¿Por qué el estándar SN 29500 es tan popular para calcular las tasas de fallos de hardware?

Respuesta breveEs la base de datos de tasas de fallos más fiable y ampliamente aceptada en la cadena de suministro del sector automotriz.

DetallesSi bien estándares como MIL-HDBK-217F o IEC/TR 62380 son útiles, SN 29500 (desarrollado por Siemens) proporciona tasas de falla actualizadas y altamente realistas para chips de silicio y componentes pasivos modernos. Su uso garantiza que sus cálculos sean coherentes con las expectativas de los fabricantes de automóviles y los proveedores de primer nivel durante las auditorías de seguridad funcional.