What is AUTOSAR Classic Platform R20-11?

By Brendan Morris

The earlier days of the AUTOSAR standard have been discussed before, by the mid 2010’s it was becoming clear that a fork in the road was approaching with the need for a more flexible approach increasingly needed. AUTOSAR, as it had been until now, became AUTOSAR Classic Platform and a new AUTOSAR Adaptive Platform was introduced to support more application like functions and flexibility on high performance compute increasingly available to the automotive industry. Subsequently functionality common to Classic and Adaptive Platforms has been moved into a Foundation standard to ensure interoperability is maintained.

AUTOSAR Standards Classic Platform and Adaptive Platform both rely on Foundation for common elements ensuring interoperability
Fig. 1 AUTOSAR Standards

Whilst AUTOSAR Adaptive Platform expands the types of ECU supported by AUTOSAR, there are many traditional ECU’s where AUTOSAR Classic Platform is still appropriate, a focus on consolidating high compute functions and services into central/zonal/domain ECU’s does not fully eliminate relatively simply function ECU’s controlling and monitoring inputs and outputs. Classic Platform is well suited to control functions with safety related functionality, with both support for upto ASIL D available and cyber security extensions to ensure freedom from interference, be it malicious or due to system faults.

Version numbers

Classic Platform was released as a numbered version until 4.4.0, where the first 4 represented the major platform version, with concept changes breaking compatibility, the second 4 represented an incremental version, where new concepts had been added meaning that the standard in itself would not be fully compatible, and the final 0 representing a minor version, with clarifications and fixes to the standard, not concept changes or additions.  All 3 parts of the standard are now released together as annual dated releases, i.e. R20-11, corresponding to November 2020. It has become normal practice for most OEM’s to work with a specific release for a generation of E/E architecture, commonly with some enhancements and/or customisations, from later (or sometimes earlier) releases, or specific to the OEM’s system design.

AUTOSAR Classic Platform
Fig. 2 AUTOSAR Classic Platform

In recent releases more effort has been placed on harmonizing the architecture and functionality between Classic and Adaptive platforms, as per the aims of the creation of AUTOSAR Foundation, simplifying deployment of both platforms working together across a production E/E architecture. By R20-11 much of this harmonization was in place, and along with improved Ethernet support including 10Base-T1S Ethernet, Wake-up over data-line, and a network learning mode, providing the capabilities needed for the mid-late 2020’s production vehicles. This builds on the additions in R19-11, which further developed Diagnostics over IP (DoIP) bringing support for onboard testers into AUTOSAR, along with other enhancements supporting Over-the-Air software updates, cyber security with the addition of the IPsec protocol. Over these releases there has also been further work to enable Classic platform to operate in a Service Oriented Architecture (SOA).

When to change AUTOSAR version

As I mentioned in my previous blog, there tends to be certain releases that are more commonly adopted by more OEM’s, mostly as a consequence of the implementation and availability of needed new concepts, from those supporting new network bus technology such as 10Base-T1S Ethernet, hardware technology on switches, micro-controllers and processors, through to cyber security enhancements and more sophisticated mode management supporting low energy use cases, and enhanced functional safety for demanding functions and services.

AUTOSAR has a long tradition of integrating with relevant standards, from ASAM, ISO, and more, supporting the needed use cases, and to maximize the available abstraction from specific hardware and software, supporting re-use. Recently it has become necessary to support concepts which could be implemented in hardware, or software extensions, enabling AUTOSAR to configure and utilize advanced hardware features without becoming constrained to any specific implementation targets.

Moving to Centralized and Zonal E/E architectures requires OEM’s to plan larger scale synchronized new generation ECU’s for many of the more powerful ECU’s on their architectures, this is commonly aligned with bringing more software, and often more ECU development in house to the OEM. This topic has been discussed in more detail in an on-demand webinar, requiring new collaborations through the value chain, and changes to the skills and process flows in the OEM’s. Siemens has solutions supporting the full development of the E/E architecture, through to Capital VSTAR, and its developer focused tooling, and virtual validation technology streamlining ECU software development.

Leave a Reply

This article first appeared on the Siemens Digital Industries Software blog at