ISO 26262 es la norma de seguridad funcional para vehículos de carretera, y el término que más se busca de ella es ASIL. Quien llega aquí suele venir de una reunión en la que le han dicho que su componente «es ASIL B» y quiere saber qué significa eso para su trabajo. Vamos a ello: de dónde sale el nivel, qué obliga a hacer y dónde están los errores que cuestan dinero.
Qué es ISO 26262
Su título es Road vehicles — Functional safety. La primera edición es de 2011 y la segunda, de 2018, amplió el alcance a camiones, autobuses y motocicletas, además de aclarar el tratamiento de los componentes desarrollados fuera de un vehículo concreto.
La norma es una adaptación al automóvil de IEC 61508, la norma madre de seguridad funcional. Se organiza en doce partes que recorren el ciclo de vida completo: gestión, concepto, desarrollo de sistema, de hardware y de software, producción y operación, procesos de apoyo, y guías.
Su objeto es acotado y conviene tenerlo claro desde el principio: ISO 26262 se ocupa de los riesgos derivados del mal funcionamiento de sistemas eléctricos y electrónicos. No se ocupa de que el sistema esté mal pensado aunque funcione perfectamente —eso es SOTIF— ni de que alguien lo ataque —eso es ciberseguridad—. Confundir estos tres ámbitos es el malentendido más caro del sector.
De dónde sale el ASIL: el análisis HARA
El ASIL (Automotive Safety Integrity Level) no se elige ni se hereda del proveedor: se calcula, para cada situación peligrosa, mediante el análisis de peligros y evaluación de riesgos, el HARA. Se valoran tres factores:
- Severidad (S0 a S3): qué daño se produce si el peligro se materializa. S0 es sin lesiones; S3, lesiones mortales o críticas con probabilidad de supervivencia incierta.
- Exposición (E0 a E4): con qué frecuencia el vehículo está en esa situación operativa. Circular por autopista es alta exposición; estar en un túnel de lavado, baja.
- Controlabilidad (C0 a C3): si un conductor medio puede evitar el daño. C0 es controlable en general; C3, difícilmente controlable o incontrolable.
Cruzando los tres se obtiene QM (solo gestión de calidad, sin requisitos de la norma) o ASIL A, B, C o D, siendo D el más exigente. Y aquí está la primera idea que hay que interiorizar: el ASIL es de la situación peligrosa, no del componente. Un mismo controlador puede acabar albergando funciones ASIL D y funciones QM.
La segunda: el HARA se hace sobre una definición del elemento clara. Sin saber exactamente qué hace el sistema, dónde empieza y dónde termina, con qué interactúa y en qué situaciones se usa, el HARA no vale nada. La mayoría de los problemas de un proyecto de seguridad funcional nacen de una definición del elemento escrita deprisa.
De los objetivos de seguridad a los requisitos
De cada situación peligrosa sale un objetivo de seguridad, redactado en lenguaje de sistema y no de implementación: «evitar la aplicación no intencionada del par motor superior a X Nm». Ese objetivo hereda el ASIL del peligro y lleva asociado un intervalo de tiempo tolerable al fallo, el FTTI: cuánto puede durar el estado incorrecto antes de que haya consecuencias.
El FTTI es el parámetro que condiciona toda la arquitectura. Si tienes 100 milisegundos para detectar un fallo y llevar el sistema a un estado seguro, eso determina la frecuencia de los diagnósticos, el tiempo de respuesta de las comunicaciones y hasta la elección del microcontrolador.
A partir del objetivo se despliegan los requisitos funcionales de seguridad, después los técnicos, y de ahí a hardware y software. Toda la cadena tiene que ser trazable en los dos sentidos, igual que en aeronáutica.
La descomposición de ASIL: la herramienta que ahorra dinero
La norma permite repartir un requisito de alto ASIL entre dos elementos suficientemente independientes, de modo que cada uno asuma un nivel menor. Un requisito ASIL D puede descomponerse, por ejemplo, en ASIL B(D) + ASIL B(D), o en ASIL D(D) + QM(D). La notación entre paréntesis recuerda de dónde viene el requisito, que es una información que no se puede perder.
La condición es independencia demostrada: hay que hacer un análisis de interferencias y justificar que un fallo no afecta a ambos caminos. Compartir alimentación, reloj, memoria o bus suele arruinar la independencia. Por eso la descomposición es una decisión de arquitectura temprana, no un truco documental de última hora.
Las métricas de hardware que hay que demostrar
Esta es la parte que más se subestima en los calendarios. Para hardware, la norma exige demostrar valores objetivo de tres magnitudes:
- SPFM, cobertura frente a fallos de punto único: ≥90 % para ASIL B, ≥97 % para C y ≥99 % para D.
- LFM, cobertura frente a fallos latentes: ≥60 % para B, ≥80 % para C y ≥90 % para D.
- PMHF, probabilidad de fallo peligroso por hora: del orden de 10⁻⁷ para ASIL B y C, y 10⁻⁸ para ASIL D.
Alcanzar un 99 % de cobertura no se consigue añadiendo diagnósticos al final: se consigue eligiendo componentes con datos de fiabilidad disponibles, diseñando la arquitectura con mecanismos de seguridad desde el principio y haciendo el análisis FMEDA en paralelo al diseño, no después.
Confirmación: quién revisa a quién
ISO 26262 define medidas de confirmación con distintos grados de independencia según el ASIL:
- Revisiones de confirmación de los entregables clave, incluido el propio HARA.
- Auditoría de seguridad funcional: ¿se está siguiendo el proceso que se dijo?
- Evaluación de seguridad funcional: ¿el resultado es realmente seguro?
Para ASIL D, estas actividades exigen independencia organizativa: no pueden hacerlas personas que dependan de la misma línea jerárquica que el equipo de desarrollo. Eso tiene consecuencias de plantilla que conviene prever antes de ofertar un proyecto.
Elementos fuera de contexto
Muchos proveedores no desarrollan para un vehículo concreto, sino un producto que se venderá a varios fabricantes. La norma lo contempla mediante el concepto de elemento fuera de contexto: se desarrolla bajo hipótesis declaradas sobre su uso, y el integrador comprueba después que esas hipótesis se cumplen en su vehículo.
Esto, que parece un detalle, es la base del modelo de negocio de medio sector: permite vender el mismo controlador a tres fabricantes con el mismo expediente de seguridad. La condición es que las hipótesis estén escritas de forma verificable, no como una declaración genérica de buenas intenciones.
SOTIF y ciberseguridad: las otras dos normas
ISO 26262 cubre el fallo. Pero un sistema de asistencia a la conducción puede provocar un accidente sin fallar: porque el sensor no reconoció una situación, porque el algoritmo generalizó mal o porque el conductor usó la función de forma no prevista. De eso se ocupa ISO 21448 (SOTIF), la seguridad de la funcionalidad prevista, y su importancia crece con cada nivel de automatización.
Y un sistema puede comprometerse porque alguien lo ataque: ahí entra ISO/SAE 21434 de ciberseguridad, junto con los reglamentos UNECE R155 y R156, que obligan a disponer de un sistema de gestión de ciberseguridad y de actualizaciones de software para poder homologar.
En un programa actual las tres disciplinas comparten análisis, reuniones y evidencias. Quien entiende las tres y sabe articularlas es el perfil que más demanda tiene. Esa combinación se trabaja en el programa de seguridad funcional y ISO 26262 y en los de [[homologaci[óo]n de veh|homologación de vehículos]].
Errores que más caros salen
- Hacer el HARA tarde. Si se hace cuando la arquitectura ya está cerrada, lo único que queda es documentar lo que hay y rezar para que dé los números.
- Descomponer sin demostrar independencia. Es el hallazgo más frecuente en evaluación, y obliga a rehacer arquitectura con el proyecto avanzado.
- Tratar la seguridad como un departamento. La seguridad funcional la hace el equipo de desarrollo; el equipo de seguridad la gobierna y la confirma.
- Ignorar el modo degradado. Definir el estado seguro es tan importante como detectar el fallo: un sistema que se apaga en el momento equivocado puede ser más peligroso que el fallo original.
- Olvidar producción y operación. Las partes 7 y 8 de la norma también se auditan: trazabilidad de piezas, control de cambios, gestión de campo.
Qué perfiles contrata la industria
Ingeniero de seguridad funcional, arquitecto de sistemas E/E, ingeniero de validación, responsable de homologación y gestor de ciberseguridad del producto. Contratan fabricantes, proveedores de primer nivel, ingenierías de desarrollo y servicios técnicos de homologación.
En las entrevistas lo que se evalúa es casi siempre lo mismo: que sepas razonar un HARA concreto en voz alta y defender por qué una situación es C2 y no C3. Memorizar las tablas no sirve; haberlas aplicado a casos, sí.
Un ejemplo completo: de la situación al requisito
Verlo sobre un caso concreto ahorra mucha teoría. Tomemos una función de frenada regenerativa en un vehículo eléctrico.
Situación peligrosa. El vehículo circula por autopista a 120 km/h, con lluvia, y la regeneración aplica un par de frenado en el eje trasero superior al solicitado. El vehículo pierde estabilidad.
Clasificación. La severidad es alta, porque a esa velocidad un trompo tiene consecuencias graves: S3. La exposición también, porque circular por autopista con lluvia es una situación frecuente: E4. La controlabilidad es baja, porque un conductor medio no corrige a tiempo una pérdida de adherencia en el eje trasero: C3. El cruce de S3, E4 y C3 da ASIL D.
Objetivo de seguridad. «Evitar la aplicación no intencionada de par de frenado regenerativo superior a X Nm en el eje trasero», con un intervalo tolerable al fallo de, pongamos, 80 milisegundos.
Consecuencias de diseño. Ese FTTI de 80 ms obliga a que el diagnóstico que detecta el par incorrecto se ejecute varias veces dentro de esa ventana, a que la comunicación entre el control de tracción y el de frenos tenga un tiempo de ciclo compatible, y a definir qué es el estado seguro: ¿cortar la regeneración y pasar a freno hidráulico? ¿Limitarla a un valor conservador? Esa decisión se analiza, porque cortar bruscamente también introduce una perturbación.
Descomposición. Si se quiere evitar desarrollar todo el camino en ASIL D, se puede plantear un camino principal en ASIL B(D) más un supervisor independiente en ASIL B(D) que compare el par solicitado con el aplicado y corte si divergen. Pero habrá que demostrar que ambos no comparten alimentación, reloj ni fuente de medida, y ahí es donde el ahorro se gana o se pierde.
Cómo encaja con la homologación
Conviene no mezclar dos cosas que viven en departamentos distintos. La seguridad funcional es un proceso de ingeniería interno, que se audita y se evalúa. La homologación es un acto administrativo: un servicio técnico ensaya el vehículo o el sistema contra reglamentos concretos y emite un certificado.
Durante años fueron mundos separados. Han dejado de serlo con los reglamentos UNECE que exigen sistemas de gestión: R155 obliga a disponer de un sistema de gestión de ciberseguridad y R156 de un sistema de gestión de actualizaciones de software, y ambos se auditan como condición previa para homologar. El resultado es que un proveedor ya no puede limitarse a entregar un producto correcto: tiene que entregar la evidencia de cómo lo ha desarrollado y cómo lo mantendrá actualizado durante su vida útil.
Para quien trabaja en ingeniería de producto esto significa que la documentación de seguridad funcional ha dejado de ser un trámite interno y forma parte del expediente que decide si un vehículo se puede vender.
Preguntas frecuentes sobre ISO 26262 y ASIL
¿Qué significa QM?
Que para esa situación peligrosa basta con un sistema de gestión de la calidad; no aplican los requisitos de ISO 26262. No significa que el componente sea irrelevante ni que se pueda desarrollar sin rigor.
¿Un componente puede ser ASIL D entero?
Puede, pero rara vez conviene. Lo habitual y lo más barato es segregar: que solo la parte que realmente implementa el objetivo de seguridad soporte el nivel alto, y el resto quede en un nivel inferior con independencia demostrada.
¿ISO 26262 es obligatoria por ley?
No es una ley, es el estado del arte reconocido. En la práctica, los fabricantes la exigen contractualmente a sus proveedores y es el criterio con el que se juzga la diligencia debida si hay un incidente.
¿Se aplica a vehículos eléctricos y a motocicletas?
Sí. La segunda edición incorporó explícitamente las motocicletas, con un esquema propio de clasificación, y los sistemas de alta tensión de los eléctricos son uno de los ámbitos donde más se aplica.
Formaciones de SEIUM relacionadas con seguridad funcional en automoción
- Máster en Ingeniería de Evaluación de Políticas Urbanas Basadas en Datos
- Máster en Ingeniería de Seguridad activa/pasiva, ADAS & autónomos
- Máster en Ingeniería de ADAS y Conducción Autónoma
- Máster en Ingeniería de SOTIF & Seguridad Funcional Integrada
- Máster en Ingeniería de Camiones y Buses Clásicos — frenos neumáticos, transmisiones pesadas, documentación específica.
