Software is critical to modern automobiles. The ever-increasing complexity of automotive embedded electronics results in huge amount of data collection and processing in real-time. Is Classic AUTOSAR platform equipped for this? What is Adaptive AUTOSAR? Can Classic and Adaptive AUTOSAR co-exist? Let’s Find out!
Case for a New AUTOSAR Platform: The Adaptive AUTOSAR
Let’s start by taking a stroll in the lanes of automotive history! Roughly in 1980’s the automotive industry welcomed its first electronic control unit. Back then, the ECU was responsible for controlling the air-fuel ratio, variable valve timing and a few other engines related stuff. Software embedded inside the ECUs were simpler in terms of size, complexity and computing prowess.
Fast forward to 2020, we are inching closer and closer to perfecting autonomous driving. Today, there is telematics, infotainment clusters and a whole bunch of IoT gizmos embedded in a vehicle.
But how do you integrate so many components, possibly from different vendors, without facing compatibility issues? AUTOSAR is the answer to this!
When AUTOSAR was introduced in 2002, the idea was to bring about a standardization in the development of automotive software. It was designed to implement ECUs which had software deeply embedded in them. It was assumed that these applications would not require any kind of update during its entire lifetime.
However, there has been a sea-change in the automotive software ecosystem. Automotive software now requires frequent updates. Additionally, there is a need for flexibility and computing prowess that has never been felt before. And Classic AUTOSAR platform is not designed for this.
This does not mean that the good old classic AUTOSAR has become obsolete; rather, it needs a brother-in-arms that can cater to the changing needs of future generation automobiles.
Let’s Analyse the Need for the Adaptive AUTOSAR Platform in 3 Cases:
Case 1: ADAS: Advanced Driver-Assistance System is based on an intricate set of sensors like LIDAR, RADAR and high-resolution cameras. The data collected from these sensors need to be processed to create a model of the environment outside of the vehicle. Based on this environment model, ADAS assists the driver during braking, parking or even driving (as in the case of autonomous driving).
In fact, autonomous driving has been the biggest drivers of the introduction of a new AUTOSAR architecture that can support dynamic communication, a flexible and secure platform, faster data communication and processing, and more.
A Moment in the Life of an Autonomous Vehicle:
- Observe the environment outside the car very minutely using sensors and cameras
- Communicate with the environment such as traffic lights, other cars, etc.
- Utilize the data collected from the sensors to make driving decisions such as left/right maneuver, slowing down, sudden braking, and so on..
The images captured by the cameras and the RADARS in an autonomous car must be transported to the ECU for processing in real-time. To achieve such fast communication, in-vehicle BUS System like CAN, LIN, Flexray, etc. is not enough. Ethernet takes precedence here and is bolstered by modern protocols like SOME/IP.
Case 2: Vehicle Architecture: When we talk about Vehicle to X communication (V2X) or vehicle-to-vehicle communication, we are looking at a completely modified vehicle architecture. Unlike traditional control units which are directly connected to sensors/cameras, a new concept of Domain Controller Architecture is trending in the automotive domain. Instead of using separate Controllers, a powerful controller is assigned for each domain such as Body Control, Infotainment, Powertrain.
In the case of Electric Vehicles, the communication between the charging station and the vehicle is also unique and must be secure for billing purpose. A strong commuting power is a must here too. And Classic AUTOSAR platform is simply not designed for such computation requirements.
Case 3: Firmware-Over-The-Air Update (FOTA): Most of the software embedded inside the ECU never require updates. A few that do require the updates have to be brought to the garage for the same.
Classic AUTOSAR is capable of providing FOTA services, but it is not best suited for it. Also, it is not possible to update individual applications inside an ECU. The flexibility issue along with stringent real-time requirements of Classic AUTOSAR also make it less reliable for FOTA.
Adaptive AUTOSAR’s flexible integration environment enhances the capability of the software to be updated and extended with new features.
A Comparison Between Classic and Adaptive AUTOSAR
| Classic AUTOSAR | Adaptive AUTOSAR |
| The communication is signal based and is achieved by the communication BUS network such as CAN, LIN, etc. | It is Service based communication which utilizes Ethernet and SOME/IP as physical medium |
| Implementation of deeply embedded functionalities | Implementation of high-performance and computation-intensive functionalities |
| Examples of future systems: Engine Control, Braking systems, Airbag Control Unit, etc. | Examples of future systems: Over-The-Air updates (OTA), Sensor fusion Data processing, Persistence, Dynamic choosing of application packages over run-time of vehicle, etc. |
| Software update at run time is not possible, communication between the software components are hard-wired | Adaptive AUTOSAR RTE is independent of the applications and hence, Over-The-Air update is possible |
| Update in a Classic Platform implies replacement of the entire ECU code | Adaptive platforms provide the options to remove/update individual applications in an ECU |
| Classic AUTOSAR architecture’s flexibility quotient is low | Flexibility is one of the USPs of Adaptive AUTOSAR and it provides a flexible integration environment |
| It has hard real-time processing requirement (in microseconds) and meeting deadline is critical | There is a soft real-time requirement (in milliseconds) |
| Applications compliant to classic AUTOSAR are written in C Language | C++ is the language prescribed for Adaptive AUTOSAR architecture |
| An OS is not required for Classic AUTOSAR implementation | Adaptive AUTOSAR is based on POSIX operating system |
| Applications utilize AUTOSAR RTE for Scheduling of Software Components and communication between them | Applications utilize the operating system for scheduling and communication |
| It is configured in a static manner wherein every signal is defined at the time of configuration | Adaptive AUTOSAR is dynamically configured due to inherent flexibility for the applications |
A Snapshot of Classic Vs Adaptive AUTOSAR Architecture
Can Classic and Adaptive AUTOSAR Co-Exist?
As many would think of it, Adaptive AUTOSAR is not meant to replace its Classic counterpart. Instead, they are meant to co-exist in an automotive ecosystem. As both the platforms provide solutions to different problems, their co-existence gives a plethora of value-adds.
Even a modern vehicle loaded with ADAS and Telematics features, require Functional ECUs to handle an entire range of tasks (where hard real-time is mandatory). Where the Adaptive AUTOSAR would support dynamic communication for OTA upgrade, Classic AUTOSAR would provide high-safety applications deeply embedded in the ECU.
As the foundation of both AUTOSAR architecture is almost similar, there are provisions for interoperability between them.
The major change that Adaptive AUTOSAR brings to a vehicle architecture is the use of Ethernet all across the communication network. The adaptive ECUs will communicate over the Ethernet while the Classic ECUs will still be communicating over vehicle BUS networks such as CAN or LIN.
So how will the Classic and Adaptive ECUs communicate with each other?
The answer is, through the gateway ECU. The classic ECU acts as a gateway and packs the signals from the BUS system into a service that Adaptive ECU can read. A conversion of configuration format is, however, necessary in this scenario.
There is another scenario where the Classic ECU is purely signal based and cannot pack the signal into a service. Here, the Classic ECU converts the signals into UDP frames and transmit them over the Ethernet. The adaptive ECU is equipped with a ‘signal to service’ mapping feature to convert UDP frame to service.
What Does the Future Hold for AUTOSAR?
The moral of the story is that Adaptive and Classic AUTOSAR complement each other and can co-exist! While Classic platform specializes in the functional ECUs where software is deeply embedded (has scores of benefits), Adaptive platform is the futuristic one that can help realize autonomous driving functionality. And the automotive industry needs both of these in equal measures.
There could be a time when Adaptive AUTOSAR platform is used as the sole platform for ECU software development. But it’s too early to predict that.
For now, with flexible gateways, automotive engineers can only think of joining these worlds and making the most of it.
