In our previous blog, we compared the Classic AUTOSAR with its Adaptive counterpart. The idea was to highlight the need of the adaptive platform and to bring out the key differences between the two.
In this second blog on the Adaptive AUTOSAR series, we take the discussion forward by delving deeper into the Adaptive AUTOSAR platform.
Reports suggest that by 2025 more than 65% of vehicles will comprise electronic components, and software forms a major chunk of it. Not only does the software grow in number but also in complexity. Additionally, there are functional safety requirements to be fulfilled for the safety relevant components.
Adaptive AUTOSAR platform has been designed considering these requirements. So, you get more computing prowess, highly flexible software configurations and communication managers. That’s not all! The transition from multi-core processors to their advanced successors, from CAN to Ethernet/SOME IP, and Embedded C to C++ are some of disruptions the adaptive platform is likely to bring about.
Curious? Let’s cut to the chase!
What is AUTOSAR Adaptive Platform?
In the simplest terms, AUTOSAR adaptive platform is a set of mechanisms that implement the runtime for the Adaptive Applications. What we call software components in the Classic AUTOSAR environment, are termed as Adaptive Applications.
The adaptive platform offers a flexible environment where the applications can be added or modified by the ECU acting as a central server. Updating the software has become all the more important as it interacts with an ever-changing environment. Case in point- ADAS, which takes data from the surrounding infrastructure and processes it to assist the driver to drive better and safer.
AUTOSAR adaptive is based on POSIX operating system. It is one of the pre-requisites of using complex processors and offers developers the necessary building blocks to create high-performance automotive applications.
What makes this new platform ‘adaptive’ is the AUTOSAR runtime. This runtime environment essentially provides the interfaces required to integrate different applications in the ECU. These applications need not be integrated to the ECU at one time. As the name suggests, the adaptive applications can be integrated at runtime. This implies that different software can be developed and distributed for an ECU, completely independent of each other.
At the heart of an AUTOSAR adaptive platform, there is an POSIX operating system and each adaptive application is implemented as a process in this OS.
We will discuss the POSIX OS and the intricacies of the adaptive platform in the subsequent sections!
The Emergence of Intelligent ECUs
One of the major factors that has triggered the development of the adaptive AUTOSAR platform is the emergence of automotive ECUs that not only communicate within the in-vehicle network but beyond.
Popularly called Intelligent ECUs, these control units are different from the conventional ECUs in many aspects including time-constraints, safety requirements and frequency of updates.
For instance, in a V2X implementation, a vehicle ECU communicates with the outside infrastructure which is constantly being modified/upgraded. The application inside the ECU also needs to be updated in order to avoid any incompatibility issues.
Moreover, such implementations also require Machine Learning, dynamic loading of software components, use of existing libraries for data analysis and so on.
In addition to collection of the data, some of these sets of information also need to be displayed to the users on an infotainment system or a head-up display. Afterall, these are features that make an intelligent ECU.
Developing such intelligent ECUs and integrating them in a vehicle network influences the network architecture of the vehicle as well as the other conventional ECUs that communicate with them.
- The first requisite of a vehicle network to support such ECUs is high data throughput rate with minimum latency.
- Secondly, the development environment should be such that it allows software functions to be added to an ECU even after the production has started.
- Moreover, the environment must support software from third-party technology providers.
Considering all of this, it is a no-brainer to deduce that a dynamic software integration environment is what the future vehicles would require.
So how does AUTOSAR Adaptive Platform (AUTOSAR AP) achieve this? Let’s find out.
Modern Problems Require Modern Solutions
Essentially, AUTOSAR AP provides an environment that is capable of supporting high-performance computing prowess and offers flexible configuration for dynamic integration of software.
AUTOSAR AP is able to achieve this feat by two major technology accelerators- Ethernet and Multicore Processors. Complex ECU operations in applications such as ADAS and Over-the-Air (OTA) update require higher bandwidth; something that conventional CAN protocol cannot achieve. Ethernet solves this issue by offering higher bandwidth which enables accurate transfer of large messages and point-to-point communication, among others.
Higher bandwidth needs a match in terms of computing prowess, which is generated by multicore processors powered by hundreds of cores. Classic AUTOSAR platform does not support such multicore processors but Adaptive platform is designed to support them. The magic lies in the concept of parallel processing and heterogeneous computing.
Parallel processing is a self-explanatory term which refers to the execution of several processes in parallel.
Heterogeneous computing is a process to combine several computing resources like multicore, GPU (Graphic Processing Unit), etc.
We will talk about these concepts in detail in our next section.
Salient Features of Adaptive AUTOSAR that Make it Indispensable in Modern Times
There are certain features that make AUTOSAR Adaptive Platform what it is. Let’s explore them!
- Service-Oriented-Architecture: Unlike the conventional ECUs where the inter-ECU communications are defined at the configuration stage, Adaptive Applications take a service-oriented architecture (SOA) approach. In the SOA paradigm, the adaptive applications make their functionalities available as services. Other ECUs in the network can request for a particular service over the ethernet network. The ECU requesting for the service becomes the client and the one that fulfills the request assumes the role of a server. It is the SOA that allows dynamic integration of a new software at run-time. And that’s what makes AUTOSAR AP so flexible.
- POSIX (Portable Operating System Interface) Based Operating System: As mentioned earlier, POSIX based operating system is quite crucial to the adaptive platform. In order to implement the service-oriented architecture, a POSIX OS or a similar operating system is a pre-requisite. It provides a standard interface for communication between the application and the operating system. From memory allocation to scheduling, POSIX based OS makes sure that the services are distributed to the ECU network in the intended manner.
- Parallel Processing: In an SOA environment, each running application becomes a separate service that needs to be executed under a strict time constraint. When there are multicore processors running in a heterogeneous computing environment, it is the capability of parallel processing that keeps the applications running.
- Ethernet and Some/IP: The service oriented architecture implemented in the AUTOSAR AP is brought to life by Ethernet and SOME/IP. While the ethernet is the physical medium used for the communication, SOME/IP is the network protocol that acts as the middle layer. It defines the way in which the applications communicate with each other. SOME/IP also takes care of the serialization of the data sent over the Ethernet network.
- C++ as the coding language: Transition from embedded C to object oriented C++ as the coding language is an interesting and a welcome change. C++ brings with it, the virtues of object oriented programming, dynamic memory management, and an extensive set of standard libraries. All these attributes make C++ a language of choice in performance-intensive algorithm development.
Explaining the Most Important Use Case of Adaptive AUTOSAR Platform: Highly Automated Driving
We have been reiterating in the blog that Adaptive platform supports the much-needed computing prowess. Automated driving is one business use-case that has requirements that can fulfilled most effectively by an adaptive platform. Why so? Because an automated car has to:
- Collect data from hundreds of sensors
- Communicate with another vehicles, traffic lights and essentially the environment around it
- Process these humungous data sets to make accurate driving decisions
- Update the software frequently at run-time; so, there is no time to take a trip to the service center for each update
At the ECU level, these functions translate to requirements beyond the capabilities of Classic AUTOSAR which is mostly hard-wired. The AUTOSAR Adaptive Platform fulfills these requirements by steering away from hard-wired communication and adopting a service-oriented architecture. The AUTOSAR runtime is completely independent of the application. The applications make use of the brokering service provided by the platform without worrying about the underlying communication protocol. As a result, software can be added or replaced at runtime.
Designed to support multicore processors, the adaptive platform utilizes heterogeneous computing to crunch the numbers real fast. Rest of the job is done by Ethernet and SOME/IP that take care of the bandwidth for faster communication.
Conclusion
Adaptive AUTOSAR is not a replacement to its Classic counterpart. In fact, they complement each other at many levels. The recent shift of the automotive industry towards automation and communication beyond the vehicle has put Adaptive Platform on center stage.
Vehicles will evolve to necessitate higher degree of processing power and flexibility, and it looks like the AUTOSAR Adaptive Platform is all set to disrupt the industry in the future.
