Adaptive AUTOSAR vs Classic AUTOSAR:
Any possible coexistence provisions between them?

In 2002, the introduction of AUTOSAR aimed to standardize the development of automotive software for ECUs with deeply embedded software assumed not to require updates during its lifetime. However, the automotive software industry has undergone significant changes, requiring frequent updates. Additionally, the Classic AUTOSAR software architecture was developed on a robust real-time embedded OS, which could experience delays and interferences when the car is connected to the network, hindering real-time communication. This does not imply that Classic AUTOSAR is obsolete, rather, it requires a companion addressing the evolving demands of future vehicles. This is why Adaptive AUTOSAR was created to meet these requirements.
WHAT IS CLASSIC AUTOSAR?
Classic AUTOSAR refers to a set of specification used for creating embedded software platforms that handle fundamental automotive functions. In a multi-ECU setting, the Classic platforms must offer BSW and RTE abstractions, enabling OEMs and vendors to implement fundamental applications. The Basic software provides useful functions to the application developer, such as services for operating systems, network communication and management, memory, and diagnostics. As a result, the software units are not affected by the hardware environment, and the developers are mostly unaware of it, as shown in Figure 1.

Figure 1: Classic AUTOSAR Components
WHAT IS ADAPTIVE AUTOSAR?
An adaptive platform differs from a classic platform as it can handle both basic and advanced cross-domain functions on top of multi-core multi-ECU and HPC integrated environments. Advanced functions include support for communication to both on-board and off-board systems, cross-domain computing hardware, OTA, remote repair and exchange handling, and dynamic deployment of customer functions, including driving functions.
Due to the segregation of software and hardware in the Adaptive AUTOSAR, tasks are distributed differently between OEMs and suppliers. Rather than ordering a functional block as a physical device in the vehicle, it is now possible to purchase only the software. By installing apps from the app store, the driver can take on the role of a software integrator.
The illustration below shows the layers of the AUTOSAR Adaptive Platform Architecture

WHAT ARE DIFFERENCES BETWEEN CLASSIC AUTOSAR AND ADAPTIVE AUTOSAR?

Figure 2: A Snapshot of Classic vs Adaptive AUTOSAR Architecture
| Classic AUTOSAR | Adaptive AUTOSAR | |
| OS | OSEK / VDX O | POSIX PSE51 |
| Main Communication Method | Signal Communication | Service- Oriented Communication |
| Development Language | C | C++ |
| Application Execution Method | Directly execute code on ROM | Load to RAM from ROM, then execute |
| Software Updates in Run-time | No | Yes |
| Task Scheduling | Static Scheduling | Dynamic Scheduling |
| Real-time Capability | Extremely High (microsecond unit) | High (millisecond unit) |
| Processing Power | Low (~ 1000 DMIPs) | High (> 20,000 DMIPs) |
| Safety Requirements | Max. ASIL D | Min. ASIL B |
| Functionality | Fixed | Flexible |
Table 1: Comparison Table between Classic vs Adaptive AUTOSAR
While the classic standard has served the basic automotive functions of the past and present, the forthcoming functions with Internet of Things (IoT) and autonomous driving will be shouldered by the adaptive standard.
ANY POSSIBLE COEXISTENCE PROVISIONS BETWEEN CLASSIC AND ADAPTIVE AUTOSAR?
The Adaptive AUTOSAR system is not designed to replace the Classic AUTOSAR platform, rather, to enable both applications to coexist and collaborate between two platforms.
The Classic platform is suitable for scenarios requiring high security and real-time applications, so embedded software functions should be deployed on this platform. Conversely, the Adaptive platform is designed for parallel processing of big data, and high-performance computing functions should be run on it. As autonomous driving technology, IoT, and cloud technology continue to advance, Adaptive AUTOSAR is emerging to meet both current and future automotive technology needs. With its various architectures and complements, it can support a range of adaptive deployments, complex microcontrollers, and the interaction of different non-AUTOSAR systems.

Figure 3: An example of Co-Existing Scenario of Classic and Adaptive AUTOSAR
Adaptive AUTOSAR introduces a significant change to the vehicle architecture by utilizing Ethernet for communication network. While Adaptive ECUs will use Ethernet, Classic ECUs will continue to use vehicle BUS networks like CAN or LIN.
To enable communication between Classic and Adaptive ECUs, a gateway ECU is utilized. The Classic ECU acts as a gateway by packaging the signals from the BUS system into a service that Adaptive ECU can read.
However, a configuration format conversion is necessary in this case. If the Classic ECU is solely signal-based and cannot package the signal into a service, it converts the signals into UDP frames and transmits them over Ethernet. The Adaptive ECU is equipped with a ‘signal to service’ mapping feature to convert UDP frames into services.
WHAT DOES THE FUTURE HOLD FOR AUTOSAR?
The Classic platform is designed for functional ECUs whose deeply embedded software, whereas the Adaptive platform is geared towards enabling autonomous driving functionality, representing a futuristic approach. Both platforms are equally essential to the automotive industry.
While it is possible that the Adaptive AUTOSAR platform may eventually be the only platform used for ECU software development, it is too early to predict this. For now, automotive engineers can merge these two worlds by utilizing flexible gateways and maximizing their potential.
Reference Links:
https://www.autosar.org/standards/adaptive-platform
https://www.autosar.org/standards/classic-platform






20-11-2024