Consecuencias del concepto “a nivel de vehículo” en la ISO26262

Trabajando con sistemas de seguridad funcional en automoción,  surgen problemas de implementación que provienen de fallos de comprensión de la norma. Los de mayor impacto están asociados a la fase de análisis, ya que se arrastrarán durante todo el proyecto. Por ejemplo, – y esto no es privativo de la 26262- lo que sucede a la hora de determinar las responsabilidades de los diferentes actores del proyecto. No comprender ese punto conduce a perder de vista el objetivo o a resolver problemas de otros. Este tipo de errores aparecen y se propagan a todos los niveles: ingenieros que, de la noche a la mañana deben ser expertos en la norma tras una lectura, equipos de Governance que promueven procesos de gran complejidad para acciones que no corresponden, pasando por aquellos casos en los que el propio OEM confunde términos y exige traspasar responsabilidad inadecuadamente.

El objetivo de este artículo es aclarar un punto vital, y que podemos formular:

Los riesgos a considerar en esta norma son exclusivamente aquellos que afectan a las personas: usuarios del vehículo, de otros vehículos, o simplemente de la vía.

Por lo tanto:  el riesgo y los objetivos de seguridad se deben considerar a nivel de vehículo.

Los riesgos técnicos o económicos del proyecto no se analizarán en este contexto.

Sólo el OEM (fabricante) es responsable de definir los riesgos. Si trabajamos en un componente involucrado en una cadena múltiple, deberemos recibir en origen requisitos de Seguridad Funcional de alto nivel.

¿Dónde empieza el problema?

Seguramente, tiene un origen entre el punto ISO 26262-1:2018, 3.84 que dice “item: system or combinationn of systems, to which ISO 26262 is applied, that implements a function or part of a function at the vehicle level”.

Opino que tiene origen en el punto ISO 26262-1:2018, 3.84item: system or combinationn of systems, to which ISO 26262 is applied, that implements a function or part of a function at the vehicle level”.

Así, el Item Definition (ID) es una descripción de funciones del vehículo a alto nivel.  Estas funciones se implementan con una cadena de componentes (sistemas, elementos etc. según la terminología de ISO 26262). El ID es una abstracción de alto nivel (“el sistema de frenos”).

No obstante, es ambiguo; el lenguaje común nos lleva a identificar un item con algo contable, concreto. ¿El sistema es una electroválvula? Entonces el item es una electroválvula.

Si el ID es nuestro y no del vehículo a alto nivel, nuestro análisis de riesgos generará funciones de seguridad, como “la precisión de apertura ha de ser de tres grados”. Requisitos que deberemos implementar. Pero, ¿serán necesarios?

Efectos de esta confusión

En primer lugar, se pierde el sentido; surgen ideas como “mi componente ha de ser ASIL D porque su fallo provoca muertes”. Pero los riesgos a los que alude la norma no son causados por el fallo de un componente, sino de una función. Se precisa una secuencia de fallos que provoque dicho efecto. Un componente será catalogado como ASIL D, siempre que el que gobierna la cadena (el OEM) lo considere.

Consideremos una electroválvula que controla el circuito de refrigerante de una batería. Un bloqueo en el paso hará que falte refrigerante, aumentará la temperatura hasta que el litio reaccione, aparezca el fuego y arda. Pero esa situación no depende únicamente de ese componente. ¿Qué más se precisa?

  • Que falle la electroválvula y aumente gradualmente la temperatura.
  • que no se detecte el aumento de temperatura, o
  • que se detecte el aumento, pero la detección no fuerce la desconexión de la carga.
  • o que la desconexión de la carga no funcione.

Esa cadena está diseñada por el OEM. Si ignoramos esto, diseñaremos lo que pensamos que nos piden.

Tampoco se entiende el trabajo de Descomposición de ASIL (ISO26262-9:2018), orientado a descomponer las funciones de mayor nivel de integridad en subfunciones. Por este principio el OEM puede decir que la electroválvula basta con ASIL B, porque el circuito es redundante. Además,  al diseñar el componente también se aplica la descomposición de ASIL. El TIER puede decidir que su sistema se compone de dos electroválvulas ASIL B redundantes. Al ser un trabajo que se hace a nivel de vehículo y de componente (ASIL tailoring), no es fácil identificar este proceso desde fuera. El concepto de cadena de safety es muchísimo más evidente, por ejemplo, en las normas CENELEC ferroviarias.

Asimismo, se pierde la aproximación Top Down del análisis. De modo formal, el análisis de riesgos condiciona la arquitectura (a través del Functional Safety Concept y Technical Safety Concept),  no al revés.  Cuando, por necesidades del proyecto, desde safety justificamos decisiones de diseño previas, hacemos exactamente lo contrario. Con riesgo de que aparezcan problemas en la coherencia de los requisitos y la arquitectura, y finalmente en la auditoría.

Justificar un artefacto de diseño como mitigación de un riesgo requiere identificar el riesgo. Diseñamos con redundancia como contramedida, cuando demostramos que no hacerlo conlleva un riesgo inaceptable contra las personas. No obstante, puede haber riesgos que no se llegan a considerar porque “nuestro sistema lo evita”. Esto no sólo es formalmente incorrecto. Las métricas de la ISO 26262 exigen detectar los fallos críticos y la fracción de seguridad restante, y los fallos combinados de dicha fracción con otros fallos. Así,  es un error evitar consignar los riesgos que puedan violar el objetivo de seguridad porque han sido previamente cancelados por diseño. Se debe garantizar que esos riesgos evitados han sido tratados.

Para acabar, no habría problema si el OEM controlase correctamente el proyecto de Safety. Por desgracia, por falta de capacidad física o técnica se pierde el control detallado. Surgen dudas. Si con el avance del proyecto el OEM se encuentra con situaciones derivadas de la falta de comprensión del TIER, se genera desconfianza y muchos costes extraordinarios.

La responsabilidad

Al inicio de la relación entre cliente y proveedor en el marco de esta norma, existe un documento (Design Interface Agreement, DIA) que analiza punto a punto la norma, detallando quién hace cada cosa, y cómo y cuándo se deben intercambiar los work products resultantes de acuerdo a una matriz RACI.  No obstante, en ocasiones por falta de claridad, de confianza o problemas por ambas partes, no se atiende a este documento o no se comprende totalmente.

Entonces, ¿un TIER no hace análisis de riesgos en esta norma? Sí. En primer lugar, un análisis de riesgos es necesario en varias etapas del diseño, también en Safety. ¿Qué otra cosa es un FMEA en realidad? En segundo,  si un componente se diseña fuera de contexto (Out Of Context), sus riesgos serán producto de sus fallos críticos propagados a través de sus interfaces. Y esos riesgos y su tratamiento deberán encajar en el análisis del OEM.

O bien, que el componente gestione una función intrínseca de Seguridad Funcional (Un limpiaparabrisas, por ejemplo). Entonces sus fallos atentarán contra las personas.  Tendrá sentido que el análisis de riesgos y el ID involucre al componente.

Por último: no estoy diciendo que un TIER no pueda hacer un HARA completo del vehículo. Puede hacerlo a petición del OEM. Lo que afirmamos es que la responsabilidad de ese HARA será del OEM.

Conclusión

Lamentablemente, además del tiempo limitado y la falta de conocimiento profundo,  el problema que estamos consignando se agrava porque diferentes normas heredan este problema de ambigüedad. Cuando según la ISO 21434 se hace un TARA (threat analysis and risk assessment), las amenazas han de ser contempladas a nivel de vehículo. Por tanto, si nuestro trabajo se circunscribe, por ejemplo,  a un Battery Management System,  el TARA no nos corresponde en principio. Pero la norma no se define con claridad,  Una vez más, las normas ferroviarias (en este caso la 50701:2023) nos llevan ventaja y definen mucho mejor las zonas de uso.

Encontramos a menudo situaciones como las descritas, sobre todo en empresas que se incorporan a este mundo y que suman al esfuerzo de abrazar un enorme proceso de cambio, el ir generando trabajo innecesario e incoherente. Para muchas compañías, debería ser un objetivo prioritario asentar el conocimiento antes de asumir sobre estas normas otras que lo complicarán más aún. El modelo de la automoción, con la constante aparición de desafíos (Seguridad Funcional, SOTIF, Cybersecurity), y la creciente demanda de control autónomo, está impidiendo consolidar estos conocimientos de gestión.  Como asesor externo para el desarrollo, percibo que se repiten los problemas,  cada vez con mayor complejidad. La buena y mala noticias es que va a depender de las empresas aprender a naturalizar estos escenarios cuanto antes.