Conformidad de software ISO 26262 en la industria automotriz

Requisitos reglamentarios del documento WP.29 de la CEPE

El 23 de junio de 2020, la Comisión Económica de las Naciones Unidas para Europa (CEPE) publicó los requisitos reglamentarios en los que se describen los nuevos procesos y tecnologías que los fabricantes de automóviles deben incorporar tanto a su organización como a sus vehículos. Estas regulaciones también se aplican a los proveedores de nivel 1 y nivel 2 de componentes de software y hardware, incluidos los servicios móviles.

Los fabricantes de vehículos deben incorporar a la estructura organizativa un marco de gestión basado en riesgos para descubrir, analizar y protegerse contra amenazas, vulnerabilidades y ciberataques relevantes.

Las siguientes categorías requieren pruebas de ciberseguridad y aprobar inspecciones.

• La categoría M comprende los vehículos estándar de cuatro ruedas.
• La categoría N es para camionetas y furgonetas.
• Las categorías L6 y L7 incluyen coches eléctricos y capacidades autónomas.

Una calificación aprobatoria en los requisitos clave del WP.29 tanto organizativos como de vehículos significa que el fabricante recibe un certificado de cumplimiento. Los vehículos nuevos sin este certificado no se podrán vender en la UE después de julio de 2024. Tenga en cuenta que Estados Unidos no participa ni tiene sus propias regulaciones similares. Sin embargo, el futuro está por llegar.

Especias para automoción

El programa ASPICE (Automotive Software Process Improvement and Capability Determination) ofrece un marco de medición para que los evaluadores independientes evalúen la capacidad de una organización para el desarrollo de software. Garantizar la seguridad del software y la ciberseguridad no solo se encuentra dentro de los aspectos de ingeniería técnica del desarrollo del sistema electrónico, sino que también requiere que la organización incorpore procesos y controles.

Estos procesos y controles deben incluir formas de rastrear y monitorear el progreso dentro de todas las prácticas de la organización para garantizar:

1. Se han adoptado prácticas de seguridad y ciberseguridad.
2. Se cumplen los requisitos de seguridad y ciberseguridad.

Este es también uno de los dos criterios de certificación clave para el WP.29 de la CEPE sobre capacidad de ciberseguridad organizacional.

Escenarios inseguros

Se han materializado otras derivaciones de la norma ISO 26262, como la ISO/PAS 21448, más conocida como SOTIF (seguridad de la funcionalidad prevista). SOTIF le ayuda a analizar y prevenir el uso indebido de la funcionalidad prevista cuando crea una situación insegura. Por ejemplo, su vehículo se apaga inadvertidamente mientras lo conduce, debido a una actualización de software iniciada.

Las vulnerabilidades de seguridad también plantean situaciones peligrosas. Un atacante podría usar la conexión wifi del vehículo para explotar de forma remota un puerto expuesto. De alguna manera, podría abrirse paso desde el sistema de información y entretenimiento avanzado del vehículo (IVI) para tomar el control o influir en componentes críticos para la seguridad, como los frenos o la dirección, gracias a que comparten la misma infraestructura de comunicaciones.

El papel de las normas

Normas como la SAE J3061, sustituida por la ISO/SAE 21434, especifican que se debe realizar un análisis de amenazas y una evaluación de riesgos (TARA) inicial para evaluar las posibles amenazas relacionadas con la operación, la privacidad y otros factores que pueden afectar a un usuario o conductor de la vía. Si el riesgo de cualquier amenaza es suficientemente alto, entonces es necesario un proceso de ciberseguridad. Existen varios enfoques para eliminar las vulnerabilidades de seguridad y requisitos que mitiguen los riesgos. Obtenga más información sobre TARA y por qué su equipo de desarrollo necesita TARA.

Actualmente existen normas como la UL 4600 específicamente para el funcionamiento de vehículos totalmente autónomos. Esto significa que no hay supervisión humana y que la autonomía asume toda la responsabilidad. Esta norma se centra en la elaboración de un caso de seguridad para el despliegue de vehículos SAE Nivel 4/5, no en cómo probar la seguridad de los vehículos autónomos en las vías públicas. Eso implicaría una norma diferente.

Estas normas y otras desempeñan un papel crucial en la seguridad de la industria automotriz. Los fabricantes de equipos originales (OEM) asumen los costos de responsabilidad por entregar vehículos inseguros a las masas. Para mitigar estos riesgos, los OEM deben adoptar y cumplir estas normas. Sin embargo, los OEM deben exigir la misma calidad y cumplimiento por parte de sus proveedores. Una debilidad en un componente puede socavar la seguridad de todo el sistema.

Creación de estándares de codificación personalizados

Parasoft, en colaboración con algunos de sus fabricantes de equipos originales (OEM) de automóviles, ha creado estándares de codificación personalizados que incorporan MISRA, AUTOSAR C++14, CERT, CWE y otras reglas personalizadas para que las utilicen sus proveedores. Esto garantiza que exista el mismo nivel de calidad de software en toda la cadena de suministro.

Parasoft C/C++test es una solución de pruebas unificada que incluye pruebas unitarias y cobertura de código estructural como parte de su funcionalidad. Esta solución para el desarrollo de software C/C++ admite un conjunto integral de objetivos de hardware y ecosistemas de desarrollo que los proveedores y OEM pueden usar con diversas infraestructuras de desarrollo. C/C++test ha sido certificado por TÜV SÜD para su uso en sistemas críticos de seguridad. Para ADAS y automóviles conectados seguros, las integraciones perfectas de C/C++test con Prueba SOA y Virtualizar Combine pruebas de API con cobertura de aplicaciones en tiempo de ejecución y bancos de pruebas virtuales simulados.

Realización de análisis de peligros y evaluación de riesgos

En la norma ISO 26262, se debe realizar un análisis de peligros y evaluación de riesgos (HARA) en el sistema en desarrollo. Una vez completado el HARA, se asigna un ASIL al componente de software y existen niveles del A al D. El nivel A representa la asignación de peligro más baja y el nivel D representa la asignación de peligro más alta. Esto significa que el fallo de un sistema con asignación de ASIL D podría ser catastrófico.

También existe una asignación de nivel de gestión de calidad (QM), lo que significa que no hay ningún requisito de seguridad. El ASIL se asigna tomando la gravedad de la lesión por la probabilidad de la falla por la capacidad de control. La siguiente tabla detalla cada nivel de gravedad, exposición y capacidad de control.

Gravedad = ¿Cuál sería el impacto o daño si ocurriera la falla?

Exposición = La frecuencia o probabilidad de que ocurra la falla.

Controlabilidad: El grado en el que podemos garantizar que el evento no suceda.

Existen varias tablas disponibles gratuitamente que ayudan a determinar el valor ASIL. La tabla que aparece a continuación es un ejemplo de una tabla mucho más fácil de leer que muestra los niveles ASIL en colores según la gravedad, la exposición y la capacidad de control.

Seguridad activa y pasiva

Los vehículos que circulan por la carretera disponen de numerosos sistemas de seguridad, algunos de los cuales se consideran seguridad activa y otros seguridad pasiva.

La seguridad activa se utiliza para referirse a la tecnología que ayuda a prevenir un choque o accidente. Tienes el control de tracción, el sistema de frenos antibloqueo, el sistema de visión ADAS y otros.

Los sistemas de seguridad pasiva sirven para mantener seguros a los pasajeros. Por ejemplo, en caso de accidente, tienes bolsas de aire y cinturones de seguridad. El limpiaparabrisas electrónico y el cuadro de instrumentos también son sistemas de seguridad pasiva.

Realización de pruebas de verificación y validación del diseño e implementación de unidades de software

Dado que esta guía se centra en el software, es importante cubrir los siguientes aspectos: métodos de verificación y validación de pruebas recomendado por la norma. Por ejemplo, la Tabla 7 captura los métodos de verificación 1a a 1k que se aplicarán durante el diseño e implementación de la unidad. El método 1h, “Análisis de código estático”, es altamente recomendado para los niveles ASIL A a D.

Las columnas de la Tabla 7 a la derecha muestran los niveles ASIL de A a D. Un solo símbolo “+” indica que la norma lo recomienda, dos “++” indican que es muy recomendable y una “o” indica que no se recomienda.

Otros métodos clave de verificación se realizan a través del análisis dinámico, para pruebas basadas en requisitos e inyección de fallas. Por ejemplo, la Tabla 26262 de la norma ISO 8 tiene “Análisis de valores límite”. Este es un método para derivar un caso de prueba para eliminar defectos mediante la comprobación de entradas en la unidad que no son solo el mínimo, el medio y el máximo, sino los límites fuera del alcance de su rango, para ver si la unidad es lo suficientemente robusta para manejar estos casos atípicos.

Y la Tabla 9 enumera las métricas de cobertura de código estructural recomendadas para garantizar la cobertura de pruebas, eliminar el código muerto y los defectos ocultos.