AUTOSAR: Capas, Tipos y Uso Actual

En la compleja ingeniería de los automóviles modernos, el software juega un papel fundamental. Para gestionar esta complejidad creciente, especialmente con la proliferación de unidades de control electrónico (ECUs), la industria automotriz adoptó un enfoque estandarizado conocido como AUTOSAR (Automotive Open System Architecture). Este marco no solo busca la estandarización, sino también la modularidad, la escalabilidad y la reutilización del software.

AUTOSAR establece una arquitectura de software por capas, diseñada para separar la lógica de aplicación, que es independiente del hardware, del software más cercano al hardware específico. Esta separación es clave para permitir a los fabricantes de equipos originales (OEMs) y a los proveedores desarrollar y actualizar software de manera más eficiente y flexible. Dentro de esta arquitectura por capas, dos componentes principales que a menudo generan dudas son el Software de Aplicación (ASW) y el Software Básico (BSW).

¿Qué es AUTOSAR y por qué es importante?

AUTOSAR, o Arquitectura de Sistema Abierto Automotriz, es una iniciativa conjunta de fabricantes de automóviles, proveedores y otras empresas del sector. Su objetivo principal es crear un estándar común para el software automotriz, facilitando la interoperabilidad, la escalabilidad y la reutilización en diversos dominios del vehículo. Este estándar proporciona un marco bien definido para el desarrollo de software, delineando elementos esenciales, interfaces y protocolos de comunicación.

La estructura de AUTOSAR se compone de varias capas: la capa de aplicación, la capa de software básico (BSW), la capa de entorno de ejecución (RTE) y la capa de abstracción de microcontrolador. Esta estructura jerárquica permite aislar el software específico de la aplicación del hardware subyacente y los protocolos de comunicación. AUTOSAR también estandariza los protocolos de comunicación y las técnicas de gestión de red, lo que permite una comunicación fluida entre los diferentes componentes de software dentro de las ECUs del vehículo. El Communication Stack (ComStack) es un ejemplo de esto, proporcionando un conjunto estandarizado de servicios de comunicación.

Una característica fundamental es la abstracción de la ECU, que tiene como objetivo ocultar los detalles del hardware para que el software pueda desarrollarse independientemente del microcontrolador o la plataforma de hardware subyacente. Esto aumenta la portabilidad y la reutilización de los componentes de software en múltiples ECUs.

El enfoque de AUTOSAR también pone un fuerte énfasis en la configuración e integración. Los diseñadores de sistemas configuran los componentes de software según los requisitos específicos del vehículo, utilizando herramientas para generar el código y los archivos de configuración necesarios. Las interfaces estandarizadas definidas por AUTOSAR facilitan la integración de componentes de diferentes proveedores, promoviendo la adaptabilidad y la comunicación. Además, el soporte de herramientas es vital; existen diversas herramientas para ayudar en la configuración, integración y generación de código compatible con AUTOSAR, gestionando la complejidad del proceso de desarrollo.

La escalabilidad es otra ventaja clave; AUTOSAR puede aplicarse a una amplia gama de sistemas automotrices, desde ECUs pequeñas con recursos limitados hasta controladores de alto rendimiento. También incluye métodos estandarizados de diagnóstico y gestión de errores, lo que mejora la detectabilidad de fallos, la capacidad de reparación y el mantenimiento del vehículo.

AUTOSAR fomenta la libertad en la selección e integración de componentes de software de varios fabricantes, lo que estimula la competencia y la innovación entre proveedores.

Capas Clave de AUTOSAR: ASW vs BSW

Dentro de la arquitectura modular de AUTOSAR, la separación en capas es fundamental. Las dos capas principales que interactúan a través de una capa intermedia son el Software de Aplicación y el Software Básico.

Software de Aplicación (ASW)

La capa superior de la arquitectura AUTOSAR es el Software de Aplicación (ASW). Esta capa alberga las funciones de aplicación del vehículo, implementadas como componentes de software individuales (SWC - Software Components). Estos SWCs representan la lógica de negocio específica del vehículo, como el control del motor, el sistema de frenos ABS, el control de estabilidad, las funciones de infoentretenimiento, etc.

La característica distintiva del ASW es que está diseñado para ser independiente del hardware subyacente. Los desarrolladores de aplicaciones pueden centrarse en la funcionalidad sin necesidad de conocer los detalles específicos del microcontrolador, los periféricos o la red de comunicación. Los SWCs interactúan entre sí y con el hardware a través de interfaces bien definidas, sin una dependencia directa de la capa inferior.

Software Básico (BSW)

La capa inferior de la arquitectura AUTOSAR es el Software Básico (BSW). Esta capa contiene todo el software que no es específico de la aplicación y que es necesario para operar el hardware del ECU y proporcionar servicios estándar a la capa de aplicación. El BSW incluye controladores de dispositivos, servicios de comunicación (como CAN, FlexRay, Ethernet), servicios de memoria (flash, EEPROM), servicios de diagnóstico, servicios del sistema operativo (OS), servicios de gestión de estado, entre otros.

El BSW está más cerca del hardware y, por lo tanto, puede contener partes dependientes del microcontrolador o de periféricos específicos. Sin embargo, AUTOSAR estructura el BSW en módulos con interfaces estandarizadas, e incluso incluye capas de abstracción (como la capa de abstracción de microcontrolador y la capa de abstracción compleja) para minimizar la dependencia directa del hardware tanto como sea posible y permitir cierta portabilidad dentro de la capa BSW.

El Entorno de Ejecución (RTE)

Entre el ASW y el BSW se encuentra una capa de abstracción crucial llamada Entorno de Ejecución (RTE). El RTE actúa como intermediario, gestionando la comunicación y la interacción entre los SWCs de la capa de aplicación y los servicios del BSW. El RTE implementa el concepto de Bus Funcional Virtual (VFB - Virtual Functional Bus), que permite que los SWCs interactúen entre sí independientemente de dónde se ejecuten en el sistema (en la misma ECU o en diferentes ECUs).

Cuando los SWCs se asignan a las diversas ECUs, las conexiones virtuales del VFB se mapean a conexiones concretas: conexiones locales (dentro de la ECU) o conexiones a través de tecnologías de red (entre ECUs), como CAN, FlexRay o Ethernet. El RTE es el responsable de implementar este mapeo y sirve como la interfaz concreta entre SWCs individuales y también entre SWCs y el BSW en una ECU específica.

El VFB es una herramienta poderosa que desacopla las aplicaciones de la infraestructura de hardware, otorgando flexibilidad a los OEMs y proveedores para desarrollar software sin un conocimiento detallado de las tecnologías de bajo nivel. Permite escalar el sistema (cambiar el número de ECUs, la asignación de aplicaciones a ECUs, la tecnología de red, etc.) y facilita la reutilización y transferibilidad de los componentes de software. Además, el VFB ayuda a validar la comunicación entre SWCs, detectando errores de arquitectura de software.

¿Sigue Utilizándose AUTOSAR Hoy en Día?

Basado en la información proporcionada, la respuesta es un rotundo sí. AUTOSAR no solo sigue utilizándose, sino que se ha convertido en un estándar clave en la industria automotriz para el desarrollo de software embebido.

A pesar de su antigüedad (fue introducido en 2002), el marco AUTOSAR ha evolucionado para adaptarse a las crecientes demandas de los vehículos modernos. Sus características fundamentales, como la arquitectura por capas, el desarrollo basado en componentes, la abstracción del hardware, la gestión estandarizada de la comunicación y el soporte de herramientas, siguen siendo muy relevantes para gestionar la complejidad de los sistemas de software en los automóviles actuales.

Si bien la información menciona algunos inconvenientes, como la complejidad inherente del estándar, el consumo de recursos, el trabajo inicial requerido, ciertas limitaciones en el soporte estricto en tiempo real para aplicaciones muy críticas, los desafíos de compatibilidad de herramientas, la sobrecarga para proyectos pequeños y una curva de aprendizaje pronunciada, estos no invalidan su uso generalizado. Más bien, son factores a considerar al decidir su implementación.

La conclusión del texto refuerza que AUTOSAR es un estándar clave de la industria, proporcionando un enfoque estructurado para el diseño de software embebido. Aunque presenta complejidades, sus beneficios en escalabilidad, interoperabilidad y estandarización son significativos. La flexibilidad para integrar componentes de diferentes proveedores y la estandarización de interfaces son ventajas importantes que impulsan su adopción continua.

Además, la existencia y el desarrollo de una nueva plataforma, Adaptive AUTOSAR (discutida a continuación), es una clara indicación de que AUTOSAR como concepto general sigue siendo vital y se está adaptando para abordar las necesidades futuras de la industria automotriz, como la conducción autónoma, la conectividad y las actualizaciones por aire (OTA).

Por lo tanto, AUTOSAR sigue siendo un marco relevante y valioso para el desarrollo de software en vehículos modernos, especialmente para proyectos a gran escala con requisitos de software complejos donde la estandarización y la escalabilidad son primordiales.

Los Dos Mundos de AUTOSAR: Classic y Adaptive

La evolución de la tecnología automotriz, impulsada por sistemas avanzados como ADAS (Sistemas Avanzados de Asistencia al Conductor), la conducción autónoma, la conectividad V2X (Vehículo a Todo) y la necesidad de actualizaciones de software frecuentes (FOTA), ha puesto de manifiesto ciertas limitaciones del enfoque AUTOSAR original, ahora conocido como Classic AUTOSAR. Esto llevó a la introducción de una nueva plataforma: Adaptive AUTOSAR.

Classic AUTOSAR

El Classic AUTOSAR fue diseñado para implementar funcionalidades embebidas en ECUs con requisitos de tiempo real estrictos (generalmente en microsegundos). Se centra en sistemas donde el software está profundamente integrado y, tradicionalmente, no requiere actualizaciones frecuentes durante la vida útil del vehículo. La comunicación en Classic AUTOSAR se basa en señales y utiliza buses de comunicación como CAN, LIN o FlexRay. Las aplicaciones suelen escribirse en lenguaje C y la configuración es estática; la comunicación entre componentes de software (SWCs) está cableada en el RTE generado.

Ejemplos típicos de sistemas que utilizan Classic AUTOSAR incluyen el control del motor, los sistemas de frenos, las unidades de control de airbags, la dirección asistida, etc., donde la seguridad funcional y los tiempos de respuesta deterministas son críticos.

Adaptive AUTOSAR

El Adaptive AUTOSAR surgió para abordar las necesidades de los sistemas automotrices modernos que requieren alto rendimiento computacional, flexibilidad y la capacidad de manejar actualizaciones de software dinámicas. Está diseñado para casos de uso como ADAS, infoentretenimiento, pasarelas de conectividad y funciones de conducción autónoma.

A diferencia de Classic AUTOSAR, Adaptive AUTOSAR utiliza una comunicación basada en servicios, aprovechando tecnologías como Ethernet y protocolos como SOME/IP. Opera sobre un sistema operativo POSIX, lo que permite una mayor flexibilidad y capacidades dinámicas. Los requisitos de tiempo real son menos estrictos (tiempo real blando, en milisegundos) en comparación con Classic AUTOSAR. Las aplicaciones para Adaptive AUTOSAR se desarrollan típicamente en C++. Una de sus principales ventajas es la capacidad de actualizar o incluso añadir aplicaciones individualmente durante el tiempo de ejecución del vehículo, algo que no es fácilmente factible en Classic AUTOSAR.

Comparación entre Classic y Adaptive AUTOSAR

Co-existencia de Classic y Adaptive AUTOSAR

Es importante entender que Adaptive AUTOSAR no pretende reemplazar a Classic AUTOSAR. Ambas plataformas están diseñadas para coexistir en el ecosistema automotriz moderno. Un vehículo actual puede tener ECUs que requieren el determinismo y la seguridad funcional de Classic AUTOSAR (por ejemplo, para el control de frenos) y otras ECUs que necesitan la flexibilidad y el poder computacional de Adaptive AUTOSAR (por ejemplo, para el procesamiento de datos de sensores ADAS).

La coexistencia es posible gracias a la interoperabilidad entre las dos plataformas, a menudo facilitada por ECUs de pasarela (gateway). Una ECU de pasarela puede tomar señales del bus CAN (utilizado por ECUs Classic) y empaquetarlas en servicios que una ECU Adaptive pueda consumir a través de Ethernet, o viceversa. Esto permite que los dos mundos se comuniquen de manera efectiva dentro de la arquitectura del vehículo.

Ventajas y Desventajas de AUTOSAR (Resumen)

AUTOSAR, en su conjunto (incluyendo Classic y Adaptive), ofrece numerosos beneficios, pero también presenta desafíos:

• Ventajas: Estandarización, modularidad, escalabilidad, reutilización de software, abstracción de hardware, interoperabilidad entre proveedores, gestión de complejidad, soporte de herramientas, mejora en diagnóstico y gestión de errores, flexibilidad (especialmente con Adaptive).
• Desventajas: Complejidad inherente, posible mayor consumo de recursos, considerable trabajo inicial de implementación, limitaciones en tiempo real estricto (Classic), desafíos de herramientas y compatibilidad, sobrecarga para proyectos pequeños, menor versatilidad en enfoques no estándar, dependencia del ecosistema de proveedores, curva de aprendizaje pronunciada.

Preguntas Frecuentes (FAQ)

Aquí respondemos algunas preguntas comunes sobre AUTOSAR:

¿Cuál es la diferencia principal entre ASW y BSW?

La diferencia fundamental radica en su propósito y nivel de abstracción. El ASW (Application Software) contiene la lógica de aplicación específica del vehículo (por ejemplo, control de motor) y es independiente del hardware. El BSW (Basic Software) proporciona servicios de bajo nivel y controladores de hardware (por ejemplo, comunicación CAN, acceso a memoria) y está más cerca del hardware, aunque estructurado en módulos estandarizados.

¿Por qué se creó Adaptive AUTOSAR si ya existía Classic?

Adaptive AUTOSAR se creó para abordar las necesidades de los sistemas automotrices modernos con alto rendimiento y dinamismo, como ADAS, infoentretenimiento y actualizaciones OTA. Classic AUTOSAR fue diseñado para sistemas embebidos con requisitos de tiempo real estrictos y estáticos, y no era adecuado para la flexibilidad, la computación intensiva y la comunicación basada en servicios que exigen las nuevas funcionalidades.

¿Pueden Classic y Adaptive AUTOSAR funcionar juntos en el mismo vehículo?

Sí, Classic AUTOSAR y Adaptive AUTOSAR están diseñados para coexistir. Los vehículos modernos a menudo utilizan una combinación de ECUs Classic (para funciones críticas de tiempo real) y ECUs Adaptive (para funciones de alto rendimiento y conectividad). La comunicación entre ellas se gestiona típicamente a través de ECUs de pasarela (gateways) que traducen la comunicación basada en señales a comunicación basada en servicios (y viceversa).

Conclusión

En resumen, AUTOSAR se ha consolidado como un pilar en la arquitectura de software automotriz. Su estructura por capas, dividiendo claramente el ASW centrado en la aplicación del BSW orientado al hardware, mediado por el RTE y el VFB, es fundamental para gestionar la creciente complejidad del software en los vehículos.

Aunque el estándar original (Classic AUTOSAR) sigue siendo vital para funciones críticas con requisitos de tiempo real estricto, la introducción de Adaptive AUTOSAR demuestra la capacidad del marco para evolucionar y abrazar las demandas de los sistemas de alto rendimiento y la conectividad de los vehículos del futuro. La coexistencia de ambas plataformas, facilitada por la interoperabilidad, es la realidad actual en la mayoría de los vehículos avanzados.

A pesar de los desafíos asociados con su complejidad y adopción, AUTOSAR sigue siendo una herramienta indispensable para la estandarización, la escalabilidad y la innovación en la industria automotriz, permitiendo a OEMs y proveedores colaborar y desarrollar software de manera más eficiente.

Si quieres conocer otros artículos parecidos a AUTOSAR: Capas, Tipos y Uso Actual puedes visitar la categoría Automotriz.