AUTOSAR, ASPICE, FMEA… ¿qué es esto?

Los primeros coches eran prácticamente un amasijo de chapa, estructura de metal, elementos mecánicos, grasa y combustible. Ahora los coches son cada vez más complejos, con sistemas electrónicos que han complicado mucho los sistemas vistos en los últimos coches. Surgen términos como AUTOSAR, ASPICE, FMEA, etc.

Pero ¿sabes qué son realmente estos términos? Pues bien, vamos a ver de qué se trata y cómo afectan al mundo del motor.

¿Qué es AUTOSAR?

AUTOSAR nace con un propósito claro: proporcionar una arquitectura de software estandarizada que facilite el desarrollo, la integración y la administración de software en los vehículos modernos. Con este estándar, las empresas pueden colaborar y crear sistemas más escalables, eficientes y seguros.

Son las siglas de Automotive Open System Architecture, surgió en 2003 cuando grandes empresas del sector automotriz, como BMW, Bosch y Volkswagen, se unieron para desarrollar una arquitectura estándar de software que simplificara la integración de sistemas electrónicos dentro de los automóviles.

El objetivo inicial era reducir la creciente complejidad de las ECU y permitir una mayor interoperabilidad entre los distintos módulos de software y hardware que componían un vehículo. De este modo, mediante unas especificaciones muy concretas, se puede estandarizar toda su arquitectura.

La arquitectura de AUTOSAR está organizada en capas, lo que facilita la separación de funciones y la independencia entre diferentes componentes del software. Esto se traduce en que cada software puede desarrollarse de manera modular y luego integrarse con otros de forma eficiente y sin conflictos. Y, entre estas tres capas tenemos:

• Software básico (Basic Software – BSW): compuesto por controladores complejos, servicios de comunicación, servicios de sistema y memoria.
• Entorno en tiempo de ejecución (RTE): actúa como middleware entre el software de aplicación y el software básico, gestionando la comunicación.
• Capa de aplicación: donde se encuentran los componentes de software que interactúan directamente con el entorno de tiempo de ejecución para realizar funciones específicas en el vehículo.

Cada una de estas capas tiene tareas específicas y trabaja de manera concurrente para asegurar que todos los módulos de software funcionen de manera correcta, incluso en situaciones en las que hay que compartir los mismos recursos del hardware, como por ejemplo, el microprocesador de la ECU.

AUTOSAR Classic vs Adaptive

AUTOSAR se divide en dos tipos de plataformas en función de las necesidades del sistema: Classic Platform y Adaptive Platform, cuyos esquemas te los he incluido en la imagen anterior. En cuanto a las diferencias:

• Classic Platform: es ideal para sistemas de tiempo real, como los que gestionan el motor o el sistema de frenos. Se basa en una arquitectura estática y se ejecuta principalmente en un sistema operativo basado en OSEK.
• Adaptive Platform: por su parte, está diseñada para sistemas de mayor complejidad, como los que se utilizan en la conducción autónoma o en la fusión de datos de sensores. Esta plataforma ofrece una arquitectura dinámica y se basa en el estándar POSIX. Es ideal para sistemas con alta demanda de cálculo y flexibilidad.

Las diferencias clave entre ambas plataformas incluyen la capacidad de procesamiento y la flexibilidad. Si bien la Classic Platform está pensada para ECU que ejecutan tareas críticas de tiempo real, la plataforma Adaptive está diseñada para ECUs de última generación con mayores necesidades de procesamiento de datos y actualizaciones en línea.

Reglas de AUTOSAR C++14

Uno de los avances significativos que ha traído la Plataforma Adaptive es el uso de C++14 para el desarrollo de software. Este es un estándar de codificación implementado para mejorar la calidad y fiabilidad del código en sistemas de seguridad críticos. Se han establecido 342 reglas para garantizar que el código sea lo más eficiente posible, clasificadas en unas que son de cumplimiento obligatorio, otras recomendadas, etc.

El uso de estas reglas asegura que el software sea más robusto, que se detecten errores antes en el ciclo de vida del desarrollo y que se reduzcan los problemas de seguridad potenciales al mínimo. Ten en cuenta que se trata de algo crítico, como es un vehículo…

AUTOSAR y la virtualización de las ECUs

La mayoría de las ECUs en los automóviles actuales se adhieren a la arquitectura AUTOSAR, lo que permite la creación de versiones virtuales de estas ECUs conocidas como vECU (o ECU virtual). Estas vECU permiten realizar pruebas y simulaciones de manera más rápida y eficiente, eliminando la necesidad de esperar a disponer del hardware real.

Esto es especialmente útil en la fase de validación, donde se puede comprobar el funcionamiento del software con mayor rapidez y ver cómo interactúan los distintos módulos dentro de la arquitectura AUTOSAR sin preocupaciones derivadas del hardware real.

Es decir, AUTOSAR permite reducir los costes de desarrollo, mejorar la interoperatibilidad y compatibilidad entre sistemas, y hacer los sistemas más flexibles.

¿Qué es ASPICE?

Automotive SPICE, también conocido como ASPICE, es un modelo de evaluación y mejora de procesos de desarrollo de software específicamente diseñado para la industria automovilística. Se deriva de SPICE (Software Process Improvement and Capability Determination), un estándar desarrollado por la ISO y la IEC, y se ha adaptado para cumplir con los requisitos específicos del software utilizado en vehículos.

ASPICE proporciona un marco que ayuda a las empresas de vehículos a evaluar y mejorar sus procesos de desarrollo de software. Al hacerlo, las empresas no solo aseguran que sus sistemas sean eficientes, sino que también cumplen con los rígidos estándares de calidad y seguridad requeridos en la industria automotriz. Este modelo abarca todo el ciclo de vida del desarrollo de software, desde la fase de requisitos hasta las pruebas y el mantenimiento.

Una de las principales diferencias entre ASPICE y otros estándares es que, mientras que normativas como ISO 26262 se centran en la seguridad funcional de los sistemas electrónicos, ASPICE enfoca su atención en los procesos organizacionales durante el desarrollo de software, con el fin de mejorarlos y optimizarlos de forma continua.

El origen de ASPICE se remonta a mediados de la década de 1990, desarrollaron la primera versión de ASPICE, denominada V-Model for Software Development (VDA 6.3), que se lanzó oficialmente en 2003. Actualmente se ha continuado evolucionando con mejoras, para adaptarse a la actual industria.

Los objetivos son similares a AUTOSAR, es decir, mejorar la calidad del software desarrollado, y optimizar mejor os recursos.

Niveles de ASPICE

ASPICE se basa en un sistema de niveles de maduración que permite a las empresas conocer el grado en el que cumplen con los estándares del modelo. Estos niveles se evalúan durante auditorías realizadas por expertos independientes, quienes determinan el nivel de cada organización según sus procesos y productos. Los niveles van del 0 al 5, cada uno representando un mayor grado de madurez y mejora continua:

• Nivel 0: Sin cumplimiento. En este nivel, los procesos de software no están completos o no cumplen con los requisitos básicos de ASPICE. Es común en empresas nuevas o que aún no han implementado un sistema de gestión de calidad robusto.
• Nivel 1: Cumplimiento básico. En este nivel, los procesos de software están completos y documentados, permitiendo la creación de productos funcionales pero sin garantía de mejoras continuas.
• Nivel 2: Totalmente gestionado. Aquí, la empresa ha implementado procesos suficientemente fuertes como para gestionar los productos de software a largo plazo, incluyendo la gestión documental y la implementación de mejoras en el proceso.
• Nivel 3: Maduración. Las organizaciones que alcanzan el nivel 3 tienen procesos definidos y estandarizados que se siguen de manera consistente en toda la organización.
• Nivel 4: Predictibilidad. En este nivel, los procesos son tan robustos que la empresa puede prever cómo se comportarán en un futuro, permitiendo una mayor planificación y control de calidad.
• Nivel 5: Optimización continua. Este es el nivel más alto, donde la empresa no solo sigue procesos predecibles, sino que también implementa estrategias de optimización permanente para mejorar la eficiencia y la calidad de sus productos.

Gestión de riesgos en ASPICE

La gestión de riesgos es uno de los pilares más importantes de ASPICE, ya que ayuda a las organizaciones a identificar, analizar y mitigar los riesgos en el desarrollo del software automotriz. El marco de ASPICE exige que las empresas establezcan un proceso estructurado para gestionar estos riesgos, lo cual incluye pasos como la identificación de riesgos, el análisis de su impacto y la implementación de estrategias de mitigación que reduzcan la posibilidad de que estos riesgos afecten negativamente al producto final.

Además, ASPICE subraya la importancia de la monitoreo continuo del riesgo a lo largo del ciclo de desarrollo del software. Esto se logra mediante la documentación de riesgos potenciales y la evaluación constante de los posibles cambios en el entorno que puedan representar nuevas amenazas.

Ciberseguridad

La creciente conectividad de los vehículos en la era de la digitalización ha traído consigo importantes preocupaciones relacionadas con la ciberseguridad. Si bien ASPICE abarca la mejora de los procesos de software, también ha hecho esfuerzos para incluir procedimientos que aborden específicamente las amenazas cibernéticas.

Recientemente, la Asociación Alemana de la Industria Automotriz (VDA) publicó nuevas pautas de ciberseguridad dentro del marco ASPICE, destinadas a fortalecer la seguridad en el desarrollo de software automotriz frente a la creciente amenaza de ciberataques. Estas pautas introdujeron elementos clave como la obtención de requisitos de ciberseguridad y la validación de los tratamientos de riesgos, dando un enfoque estructurado para abordar las amenazas de ciberseguridad desde las primeras etapas del diseño.

Además, la trazabilidad juega un papel fundamental dentro de ASPICE, ya que permite que las organizaciones puedan rastrear de manera precisa los requisitos de software desde las fases iniciales del desarrollo hasta las pruebas y la implementación final. Esto no solo garantiza que los productos de software cumplan con los objetivos establecidos, sino que también permite identificar rápidamente cualquier incoherencia o incumplimiento normativo.

¿Qué es FMEA?

El FMEA es un método sistemático que identifica modos de falla potenciales dentro de un sistema, producto o proceso. Su objetivo es determinar cómo y por qué podría fallar un determinado componente, evaluar el impacto de ese fallo y, finalmente, implementar soluciones para reducir el riesgo de que ocurra. Cuando hablamos de un fallo, nos referimos a cualquier circunstancia en la que un sistema no cumpla con lo que se espera de él.

Además de identificar los fallos, el FMEA también nos permite analizar sus efectos. Por ejemplo, ¿qué pasaría si una sistema de frenos dejara de funcionar? Gracias al protocolo FMEA, puede ayudar a prevenir fallos futuros antes de que ocurran, mejorar la fiabilidad de los sistemas, reducir los costes asociados a los fallos, y también ofrecer un mejor soporte para el mantenimiento preventivo.

Tipos de FMEA

Hay diversas categorías de FMEA, cada una adaptada a diferentes aspectos del análisis, aunque todas persiguen un objetivo común: la identificación y eliminación de fallos antes de que ocurran. Los principales tipos de FMEA son:

• FMEA de Diseño (DFMEA): se enfoca en los fallos potenciales durante la etapa de diseño de un producto. Analiza aspectos como las propiedades de los materiales, la geometría, las tolerancias y otros factores críticos que pueden afectar la funcionalidad del producto final.
• FMEA de Proceso (PFMEA): aplicado en procesos productivos, este tipo de FMEA evalúa cómo los fallos en las distintas fases de fabricación o ensamblaje pueden afectar al producto final. Factores como errores humanos, materiales defectuosos o condiciones ambientales juegan un papel crucial en este tipo de análisis.
• FMEA de Sistema (SFMEA): se centra en fallos a nivel de sistemas completos, analizando cómo las interacciones entre los diferentes componentes pueden generar problemas que afectan al conjunto.
• FMEA de Máquina (MFMEA): su objetivo es examinar los modos de falla de la maquinaria, evaluando cómo una falla puede afectar a subsistemas y componentes específicos.

Pasos para realizar un Análisis FMEA

La metodología FMEA sigue una serie de pasos que permiten identificar y mitigar los riesgos. Veamos los detalles de cada uno:

1. Definir el alcance: el primer paso es determinar qué sistema, producto o proceso se va a analizar. Esto implica una comprensión profunda de las necesidades del cliente y de los objetivos del análisis. Es importante identificar qué tipo de FMEA se va a realizar: diseño, proceso o máquina.
2. Selección del equipo: debe ser llevado a cabo por un equipo multidisciplinario. Incluir expertos de diferentes áreas garantiza que se consideren todos los posibles escenarios y modos de falla, aumentando así la efectividad del análisis.
3. Identificación de modos de falla: en esta etapa, el equipo debe describir todas las formas en que puede fallar el sistema. Cada uno de estos modos de fallo será posteriormente analizado para determinar su impacto potencial.
4. Identificación de efectos de la falla: una vez que se han identificado los modos de falla, es el momento de analizar qué podría suceder si ocurre cada uno de ellos. ¿Provocará el fallo un paro total de la producción? ¿Aumentará el riesgo de accidentes? Los efectos deben ser claramente definidos.
5. Evaluación de Severidad (S): el impacto de cada modo de falla se evalúa en base a su gravedad. Generalmente, se utiliza una escala del 1 al 10, donde 1 representa un efecto mínimo y 10 una consecuencia desastrosa.
6. Identificación de las causas de la falla: esta etapa tiene como objetivo descubrir las posibles causas que pueden conducir a un fallo. Aquí entran en juego factores de diseño, errores operatorios o defectos de materiales.
7. Evaluación de la Ocurrencia (O): a continuación, se evalúa la probabilidad de que ocurra el fallo, también utilizando una escala del 1 al 10. Un valor bajo indica que la probabilidad de ocurrencia es muy reducida, mientras que un valor alto sugiere que el fallo es muy probable.
8. Controles de Detección (D): los controles actuales deben ser evaluados en términos de su capacidad para detectar los modos de falla antes de que alcancen al cliente final. Se utiliza nuevamente una escala del 1 al 10, siendo 1 una alta probabilidad de detección y 10 una baja posibilidad de identificar el problema antes de que ocurra.
9. Cálculo del Número de Prioridad de Riesgo (NPR): es un valor que se obtiene multiplicando las puntuaciones de Severidad, Ocurrencia y Detección. Este número nos permite priorizar los problemas más graves. Cuanto mayor sea el NPR, mayor será la prioridad para implementar una solución.

Por ejemplo, imaginemos que estamos analizando el proceso de prueba de un coche recién ensamblado. Los posibles modos de falla podrían ser que el coche no frene o no arranque. Uno de los efectos podría ser un accidente, lo que se consideraría muy grave, con una Severidad de 10 en la escala. Supongamos que el problema en el sistema de frenos tiene una probabilidad alta de ocurrencia, por lo que se le asigna un 7. Los actuales controles de detección, como el análisis de ruidos en los frenos, tienen una probabilidad moderada de identificar el fallo, por lo que se asigna un 2.

El cálculo del NPR sería:

NPR = 10 x 7 x 2 = 140

Este valor alto sugiere que es urgente implementar mejoras, como un mejor control de calidad para el sistema de frenos. Si por ejemplo lo comparamos con otros sistema como el embrague, con valores de S=9, O=6 y D=1, del que tendríamos un NPR = 54, por lo que al ser más pequeño el valor, menor será la prioridad para implementar una solución. Así se pueden ir evaluando cuáles son los prioritarios por parte del fabricante.

Imágenes | Canva