AUTOSAR
| AUTOSAR GbR | ||
|---|---|---|
 | ||
| Tipo | organización | |
| Industria | Automoción, E/E, Software, Semiconductores | |
| Forma legal | GbR | |
| Fundación | 2003 | |
| Presidente |
Michael Niklas-Höret (Chairperson, 2024) Thomas Rüping (Deputy Chairperson, 2024) Carmine De Iesu (Project Lead Speaker, 2024) | |
| Miembros | 366 empresas (12/2023) | |
| Estructura | ||
| Sitio web | www.autosar.org | |
AUTOSAR (AUTomotive Open System ARchitecture) es una asociación de desarrollo a nivel mundial formada por entidades interesadas en la industria del automóvil y fundada en 2003. Persigue crear y establecer una arquitectura de software abierta y estandarizada para las unidades de control electrónico (Electronic Control Units - ECU) para la automoción. Sus objetivos incluyen la escalabilidad a diferentes variantes de vehículos y plataformas, la transferibilidad del software, el tener en consideración los requisitos de disponibilidad y seguridad, el ser un marco de colaboración entre varios socios, el uso sostenible de recursos naturales y el mantenimiento a lo largo de todo el “Ciclo de vida del vehículo”.
Historia
[editar]La asociación de desarrollo AUTOSAR se formó en julio de 2003 por BMW, Robert Bosch GmbH, Continental AG, Mercedes-Benz Group AG, Siemens VDO y Volkswagen AG para desarrollar y establecer un estándar industrial abierto para la arquitectura E / E para la automoción. En noviembre de 2003, Ford Motor Company se unió como socio principal, y en diciembre se unieron Stellantis NV y Toyota Motor Corporation. El siguiente noviembre, General Motors Corporation también se convirtió en socio principal. Después de ser adquirida por Continental en febrero de 2008, Siemens VDO dejó de ser un socio principal autónomo de AUTOSAR.
Desde 2003, AUTOSAR ha proporcionado cuatro versiones mayores de la arquitectura de software estandarizada para su Classic Platform y una versión para las pruebas de aceptación. El trabajo en Classic Platform de AUTOSAR se puede dividir en tres fases:
- Fase I (2004-2006): Desarrollo básico del estándar (versiones 1.0, 2.0 y 2.1)
- Fase II (2007-2009): Extensión del estándar en términos de arquitectura y metodología (versiones 3.0, 3.1 y 4.0)
- Fase III (2010-2013): Mantenimiento y mejoras seleccionadas (versiones 3.2, 4.1 y 4.2)
En 2013, el consorcio AUTOSAR entró en un modo de trabajo continuo para Classic Platform para mantener el estándar y proporcionar mejoras seleccionadas (que incluyen la Versión R4.2 y la Versión 1.0 de las pruebas de aceptación).
En 2016 comenzó el trabajo en Adaptive Platform. Un primera versión (17-03) fue publicada a principios de 2017, seguida por la versión 17-10 en octubre de 2017 y la versión 18-03 en marzo de 2018. El objetivo es concluir las principales actividades de desarrollo de una versión conjunta de AUTOSAR Classic, Adaptive y Foundation en octubre del año 2018.
En diciembre de 2023, AUTOSAR R23-11 fue virtualmente anunciado [1]
Concepto y objetivos
[editar]AUTOSAR proporciona un conjunto de especificaciones que describe módulos de software básicos, define las interfaces para las aplicaciones y construye una metodología de desarrollo común basada en el formato de intercambio estandarizado. Los módulos de software básico puestos a disposición por la arquitectura de software en capas de AUTOSAR se pueden usar en vehículos de diferentes fabricantes y componentes electrónicos de diferentes proveedores, reduciendo así los gastos de investigación y desarrollo y dominando la creciente complejidad de las arquitecturas electrónicas y de software para la automoción. Basado en este principio rector, AUTOSAR se ha diseñado para allanar el camino a sistemas electrónicos innovadores que mejoren aún más el rendimiento, la seguridad y la protección del medio ambiente y para facilitar el intercambio y la actualización de software y hardware durante la vida útil del vehículo. Aspira a estar preparado para las nuevas tecnologías y a mejorar la relación coste-eficiencia sin hacer ningún compromiso con respecto a la calidad.
Arquitectura de Software
[editar]AUTOSAR usa una arquitectura de tres capas:
- Software básico: módulos de software estandarizados (en su mayoría) sin ningún trabajo funcional en sí, que ofrecen los servicios necesarios para ejecutar la parte funcional de la capa de software superior.
- Entorno en tiempo de ejecución (Runtime environment - RTE): Middleware que abstrae de la topología de la red para el intercambio de información inter e intra-ECU entre los componentes de software de aplicación y entre el software básico y las aplicaciones.
- Capa de aplicación: componentes de software de aplicación que interactúan con el entorno en tiempo de ejecución.
Metodología de AUTOSAR
[editar]- La descripción de la configuración del sistema incluye toda la información del sistema y la información que debe ser acordada entre diferentes ECU (por ejemplo, la definición de señales de bus).
- Extracto de ECU: contiene la información de la Descripción de configuración del sistema necesaria para una ECU específica (por ejemplo, aquellas señales a las que tiene acceso una ECU específica).
- Descripción de la configuración de ECU: contiene toda la información de configuración del software básico que es local para una ECU específica. Utilice esta información para compilar el software ejecutable, el código de los módulos de software básico y el código de los componentes de software.
Classic Platform (Plataforma Clásica)
[editar]Classic Platform de AUTOSAR es el estándar para ECUs embarcadas de tiempo real basadas en OSEK. Su entregable principal es un conjunto de especificaciones.
La arquitectura de Classic Platform de AUTOSAR distingue en el nivel de abstracción más alto entre tres capas de software que se ejecutan en un microcontrolador: aplicación, entorno en tiempo de ejecución (RTE) y software básico (Basic Software - BSW). La capa de software de la aplicación es principalmente independiente del hardware. La comunicación entre los componentes de software y el acceso al BSW ocurre a través del RTE, que representa la interfaz completa para las aplicaciones.
El BSW se divide en tres capas principales y controladores complejos:
- Servicios
- Abstracción de la ECU
- Abstracción de microcontroladores
Los servicios se dividen además en grupos funcionales que representan la infraestructura de los servicios de sistema, memoria y comunicación.
Un concepto esencial de Classic Platform es el bus funcional virtual (Virtual Functional Bus - VFB). Este bus virtual es un conjunto abstracto de RTEs que aún no han sido desplegadas en ECUs específicas y desacopla las aplicaciones de la infraestructura. Se comunica a través de puertos dedicados, lo que significa que las interfaces de comunicación del software de la aplicación deben estar asignadas a estos puertos. El VFB maneja la comunicación dentro de la misma ECU y entre las ECU. Desde el punto de vista de la aplicación, no se requiere un conocimiento detallado de las tecnologías o dependencias de bajo nivel. Este hecho da soporte al desarrollo y al uso del software de aplicación de forma independiente del hardware.
Classic Platform también permite la integración de sistemas que no son AUTOSAR como GENIVI mediante el uso del lenguaje de descripción de la interfaz de Franca (IDL)
Adaptive Platform (Plataforma Adaptativa)
[editar]Nuevos casos de uso requirieron el desarrollo de Adaptive Platform. Un ejemplo destacado es la conducción altamente automatizada (highly automated driving), en dicho contexto el conductor transfiere de forma temporal y / o parcial la responsabilidad de conducir al vehículo. Esto requiere, por ejemplo, comunicación con infraestructura de tránsito (por ejemplo, señales de tránsito y semáforos), servidores en la nube (Cloud servers) (por ejemplo, para acceder a la última información de tránsito o datos de mapas) o el uso de microprocesadores y hardware de alto rendimiento computacional para procesamiento en paralelo (por ejemplo, GPUs).
Además, las aplicaciones Car-2-X requieren interacción con vehículos y sistemas externos. Eso significa que el sistema debe proporcionar comunicaciones seguras a bordo, soporte de plataformas de computación entre dominios, integración de teléfonos inteligentes, integración de sistemas que no sean AUTOSAR, y demás. Los servicios basados en la nube también requerirán medios dedicados a la seguridad, como la interacción segura en la nube y la prioridad de vehículos de emergencia. Ello permitirá servicios remotos y distribuidos, por ejemplo, diagnóstico remoto, actualización por aire (over the air:OTA), gestión de reparación y reemplazo.
Para dar soporte al despliegue dinámico de aplicaciones de cliente y proporcionar un entorno para las aplicaciones que requieren de una potencia computacional de alto rendimiento, AUTOSAR actualmente está estandarizando Adaptive Platform de AUTOSAR. Su núcleo es un sistema operativo basado en el estándar POSIX. El sistema operativo se puede usar desde la aplicación a través de un subconjunto de POSIX de acuerdo con IEEE1003.13 (es decir, PSE51). Una de las características clave de la Plataforma Adaptativa es la comunicación orientada a servicios.
Para Adaptive Platform, hay dos tipos de interfaces disponibles: servicios e interfaces de programación de aplicaciones (Application Programming Interface - API). La plataforma consiste en grupos funcionales que están agrupados en servicios y los fundamentos de Adaptive Platform de AUTOSAR.
Grupos funcionales (functional clusters):
- agrupar funcionalidades de Adaptive Platform
- definir la agrupación de especificación de requisitos
- describir el comportamiento de la plataforma de software desde la perspectiva de la aplicación y la red
- pero, no restringe el diseño SW final de la arquitectura que implementa Adaptive Platform
Los grupos funcionales en los fundamentos del Adaptive Platform de AUTOSAR deben tener al menos una instancia por máquina (virtual) mientras que los servicios se pueden distribuir por la red interna del automóvil.
Los servicios de Adaptive Platform incluyen:
- Gestión de actualizaciones y configuración
- Gestión del Estado
- Gestión de las redes
- Diagnóstico
Adaptive Platform de AUTOSAR contiene tanto especificaciones como código. En comparación con Classic Platform, AUTOSAR Adaptive desarrolla una implementación para acortar el ciclo de validación e ilustrar los conceptos subyacentes. Esta implementación está disponible para todos los socios de AUTOSAR.
Foundation
[editar]El objetivo del estándar Foundation es reforzar la interoperabilidad entre las plataformas de AUTOSAR. Foundation contiene requisitos comunes y especificaciones técnicas (por ejemplo, protocolos) compartidos entre las plataformas AUTOSAR, así como la metodología común.
Pruebas de aceptación
[editar]En 2014, se introdujeron las pruebas de aceptación de AUTOSAR para minimizar el esfuerzo y costes de prueba. Las especificaciones para las pruebas de aceptación son especificaciones de prueba del sistema que utilizan las interfaces especificadas de la respectiva plataforma. Además, están considerando el comportamiento especificado en el bus. Se pueden ver como un caso de prueba de caja negra para una función de una plataforma en particular. La especificación de las pruebas de aceptación estándar contribuye a estos objetivos.
Interfaces de aplicaciones estandarizadas
[editar]La estandarización de las interfaces funcionales entre los fabricantes y proveedores, y la estandarización de las interfaces entre las diferentes capas de software se considera la base para alcanzar los objetivos técnicos de AUTOSAR.
Organización
[editar]AUTOSAR definió cinco tipos diferentes de miembros. La contribución de los miembros varía según el tipo de asociación:
- Socios Premium Plus (Premium Partner Plus)
- Socios Premium (Premium Partners)
- Socios Asociados (Associate Partners)
- Socios de Desarrollo (Development Partners)
- Asistentes (Attendees)
- Subscriber
Los socios principales incluyen a los socios fundadores BMW, Robert Bosch AG, Continental AG, Mercedes-Benz Group AG, Ford Motor Company, General Motors Holding LLC, Stellantis NV, Toyota Motor Corporation y Volkswagen AG. Estas compañías son responsables de la organización, la administración y el control de la asociación de desarrollo de AUTOSAR. De entre los socios principales, la Junta Ejecutiva define la estrategia general y la hoja de ruta. El Comité Directivo maneja las operaciones no técnicas diarias y la admisión de socios, relaciones públicas y asuntos contractuales. El Presidente y su delegado, designados por nueve meses, representan al Comité Directivo. El portavoz de AUTOSAR se hace cargo de la comunicación con el mundo exterior.
Los socios Premium Partner Plus pueden tener el apoyo de un Project Leader en el area técnica, organizacional y en el día día en los procesos. También dan nuevos puntos estratégicos en las juntas semanalas de los Project Leaders.
Los socios Premium y Desarrollo contribuyen con paquetes de trabajo coordinados y supervisados por el Equipo Líder del Proyecto establecido por los socios Principales. Los socios Asociados están utilizando los documentos del estándar que AUTOSAR ya haya publicado. Los Asistentes están actualmente participando con colaboración académica y proyectos no comerciales.
En diciembre de 2023, más de 350 empresas participan en la asociación de desarrollo de AUTOSAR.
Referencias
[editar]- Esta obra contiene una traducción derivada de «AUTOSAR» de Wikipedia en inglés, publicada por sus editores bajo la Licencia de documentación libre de GNU y la Licencia Creative Commons Atribución-CompartirIgual 4.0 Internacional.
Literatura
[editar]- Oliver Scheid (2015). AUTOSAR Compendium - Part 1: Application & RTE. p. 406. ISBN 978-1-50275-152-2.
- Olaf Kindel, Mario Friedrich (2009). Softwareentwicklung mit AUTOSAR (Software Development with AUTOSAR). dpunkt.verlag. p. 300. ISBN 978-3-89864-563-8.
