A Comprehensive Overview of Autosar Versioning

Autosar, the Automotive Open System Architecture, follows a meticulous versioning system to manage its development lifecycle and ensure compatibility across different releases. In this article, we'll delve into the intricacies of Autosar versioning, exploring the evolution from separate releases for Classic and Adaptive Platforms to their unified approach.

Autosar, the Automotive Open System Architecture, follows a meticulous versioning system to manage its development lifecycle and ensure compatibility across different releases. In this article, we'll delve into the intricacies of Autosar versioning, exploring the evolution from separate releases for Classic and Adaptive Platforms to their unified approach.

Development Lifecycle and Internal Release Numbers

The development lifecycle is accompanied by changes to the internal release number. The internal release number is given by R<major release>.<minor release>.<revision>, such as R3.2.2 or R4.1.1. The internal release number is used within the BSW modules, among other things. It relates to the lifecycle in the following manner:

• Major Release: Represents the final product of the development lifecycle state. It may introduce changes to valid and draft specification items, potentially rendering them non-backward compatible.

• Minor Release: Corresponds to the evolution lifecycle stage. It incorporates backward-compatible changes to valid specification items and alters draft items, which might turn them into non-backward compatible.

• Revision: Indicates the maintenance lifecycle stage. It doesn't extend the standard with new items but delivers backward-compatible bug fixes.

Version Identification and Release Date

The version of a release is identified by the year and month of the release data, such as Ryy-mm. For example, R23-11, the latest Autosar release, indicates a release from November 2023. This versioning structure was harmonized across the Adaptive and Classic Platforms starting from release R19-11.

Foundation and Platform Dependency

Until the Adaptive Platform version R19-03 and the Classic Platform version R4.4.0, the platform releases were kept separate, and the Foundation release was associated with each individual platform release. Making the Adaptive and Classic Platforms interoperable with each other means the XML schema needs to work with both. After these respective releases, both platforms and the Foundation started being released together, sharing the same number.

XML Schema and Namespace

The XML schema is the XML namespace used for Autosar XML files (ARXML). These are defined in the W3C recommendation, so that different XML elements with the same name do not collide with each other. The namespace is omitted from the ARXML files, but you will normally find it when using the files as regular XML in scripts.

Evolution of Platform Releases

The schema version for each Autosar Platform is specified in the table below, along with the relevant Foundation version, prior to R19-11. You should take special attention to it when working with multiple ECUs of different platforms:

The evolution of Autosar versioning after R19-03 is evident in the table below, showcasing the association between platform releases and their internal release numbers. This table reflects the transition from separate releases to a unified approach, where both Classic and Adaptive Platforms are released together.:

In conclusion, understanding the versioning system of Autosar is crucial for developers and engineers working with different platforms and versions. The meticulous approach ensures compatibility, evolution, and maintenance, contributing to the robustness of Autosar in the automotive industry.

Author: Micael Coutinho (opens in a new tab)

References:

• Classic Platform Release Overview - Autosar Specification (opens in a new tab)