Qué es la ISO 26262 y qué exige al proveedor

Un proveedor de módulos electrónicos para puertas cotizó un controlador de ventanas eléctricas para un vehículo nuevo. Junto con el dibujo llegó un documento que la planta nunca había visto: un acuerdo de interfaz de desarrollo con una columna de responsabilidades, una meta de seguridad clasificada como ASIL B y la lista de productos de trabajo que debía entregar. El controlador tenía que evitar que la ventana atrapara la mano de un niño, y el cliente no iba a aceptar la palabra del proveedor: quería la evidencia de cómo se había diseñado para lograrlo.

Qué es la ISO 26262

La ISO 26262 es la norma de seguridad funcional para los sistemas eléctricos y electrónicos de los vehículos de carretera. Seguridad funcional significa que el sistema no causa un riesgo inaceptable cuando falla: si un sensor se descompone o un software se equivoca, el vehículo debe detectarlo y llegar a un estado seguro. La norma cubre todo el ciclo de vida del sistema, desde el concepto hasta la producción y el retiro, y está organizada en doce partes. La edición vigente es de 2018.

Qué es el ASIL

El punto de partida es el análisis de peligros y evaluación de riesgos. Para cada peligro se califican tres factores: la severidad del daño, la exposición, es decir, qué tan seguido se presenta la situación de manejo, y la controlabilidad, qué tanto puede el conductor evitar el daño. La combinación da el nivel de integridad de seguridad automotriz, o ASIL, que va de A a D. ASIL D es el más exigente, como en la dirección o los frenos; si el riesgo no llega a ASIL A, se clasifica como QM y basta el sistema de calidad normal.

Qué exige según el ASIL

• —Metas de seguridad y requisitos de seguridad funcional y técnica que se derivan de cada peligro.
• —Métodos de diseño y verificación más rigurosos conforme sube el ASIL, en hardware y en software.
• —Métricas de hardware: cobertura de fallas de punto único, de fallas latentes y probabilidad de falla aleatoria.
• —Análisis de seguridad como el AMEF y el análisis de árbol de fallas para demostrar que los mecanismos de seguridad funcionan.
• —Medidas de confirmación: revisiones, auditoría y evaluación de seguridad funcional hechas con independencia del equipo de diseño.

Qué cambia para el proveedor

El cliente y el proveedor reparten las actividades en el acuerdo de interfaz de desarrollo, que dice quién hace cada análisis, quién entrega cada producto de trabajo y cómo se comunican los cambios. El proveedor tiene que demostrar que su organización gestiona la seguridad funcional: un responsable, personal con competencia demostrable, una cultura que permite escalar problemas de seguridad y un sistema de calidad sólido, porque la norma lo da por supuesto. La ISO 26262 no tiene certificado propio de producto; lo que el cliente evalúa es la evidencia del caso de seguridad.

Errores frecuentes

• —Tratar la seguridad funcional como un documento al final del proyecto, no como parte del diseño.
• —Firmar el acuerdo de interfaz sin entender qué productos de trabajo toca entregar.
• —Hacer la evaluación de seguridad con el mismo equipo que diseñó.
• —Cambiar componentes o software en producción sin evaluar el efecto en las metas de seguridad.

Dónde se complica en la operación

En Puebla, donde los proveedores de autopartes empiezan a fabricar módulos con electrónica y software para las armadoras, la ISO 26262 suele llegar con un proyecto ya cotizado y una fecha de arranque. Lo que más cuesta no es el análisis técnico, sino la base que la norma supone: control de cambios, competencia documentada, gestión de proveedores y auditorías internas que funcionan. Esa base es parte de lo que se trabaja en la Consultoría ISO 9001 en Puebla.

En resumen

La ISO 26262 es la norma de seguridad funcional para sistemas eléctricos y electrónicos de vehículos. Clasifica cada peligro en un ASIL de A a D según severidad, exposición y controlabilidad, y exige métodos de diseño, métricas, análisis de seguridad y medidas de confirmación proporcionales a ese nivel, repartidos entre cliente y proveedor en un acuerdo de interfaz de desarrollo.