AUTOSAR – what exactly is that?

AUTOSAR (Automotive Open System Architecture) is an industrial standard for software architecture created by a group of automotive manufacturers, suppliers and electronics companies. It was conceived to reduce the complexity and incompatibility of electronic and software components in modern vehicles. Among the companies involved were, for example, BMW, Bosch, Continental, Daimler, Ford, General Motors, PSA, Toyota and Volkswagen.

AUTOSAR has the fundamental potential to achieve enormous savings by – at least in theory – reducing development time, increasing code reusability and improving component compatibility. According to a study by the consulting firm McKinsey, savings from the use of AUTOSAR in the automotive industry can be as high as 30%. However, it should also be mentioned that these are theoretical notions that may sometimes differ in practice, and that the ability to develop across platforms is the greater advantage.

AUTOSAR Adaptive, which was introduced in 2016, differs from the original Classic version in its ability to change the functionality of software components during runtime. This enables more flexible use of resources and facilitates the integration of new functions and components – and that is important because: The requirements for ECUs have changed due to e.g. connected cars and autonomous driving. Vehicles must be highly networked and able to communicate with cloud-based services. In addition, ECUs (Electronic Control Unit) must be able to calculate complex ADAS algorithms (Advance Driver Assistance System), which increases the demands on computing power. This results in further hardware architectures, which in turn have new requirements for software that AUTOSAR Classic could not fulfill. The reason for this is that Classic platforms (ECUs) are microcontroller-based, while Adaptive platforms are CPU-based, keyword High Performance Computing.

For more information about AUTOSAR and its applications in detail you can visit the official AUTOSAR website: www.autosar.org. In this article, however, we will now focus primarily on the structural peculiarities of AUTOSAR and ask how promising AUTOSAR will remain as a basis for domain middleware in the future, not least in view of the emergence of new players such as Apex.AI.

Structural view of AUTOSAR – The layers

AUTOSAR defines a standard architecture for software development in the automotive industry. AUTOSAR Classic is divided into three layers: The application layer, the basic software layer and the runtime layer. Within each layer, different modules are defined that provide specific functionalities. The main concept here is that the applications in the application layer are independent of hardware and thus more easily portable. The basic software layer includes modules for basic ECU functionality, such as access to sensors and actuators, signal processing and network functions. The runtime environment is responsible for the execution of applications and basic software and thus represents the runtime infrastructure for AUTOSAR.

In comparison, AUTOSAR Adaptive introduced a completely new architecture. Particularly noteworthy is the service layer, which allows functionalities to be changed during runtime and thus offers greater flexibility in the development and integration of new functions.

Application examples for the AUTOSAR architecture are numerous. For example, Continental uses AUTOSAR to integrate electric motors in hybrid and electric vehicles to ensure uniform control of the motors and efficient use of the batteries – which does not mean that these functions could not be implemented elsewhere. However, these are typical functions for AUTOSAR. Bosch is currently using AUTOSAR, for example, in the development of driver assistance systems in order to achieve uniform processing of sensor signals and simpler integration into the overall system.

Details are important: AUTOSAR Classic explained

AUTOSAR Classic was originally introduced to reduce the complexity of software development in the automotive industry. By defining a standard architecture, different companies were able to develop software modules that were compatible with each other. One example of this is the collaboration between BMW and Continental, which has developed a joint platform for vehicle electronics based on the AUTOSAR Classic architecture. AUTOSAR Classic is generally limited to fixed functions and features, but offers better control over memory and processor usage. IHS Markit estimates that companies using AUTOSAR Classic can reduce development time by up to 20 percent and cut software costs by up to 30 percent.

This almost automatically brings new questions, for example: Can AUTOSAR Classic only be used for defined functions and properties or can it also be used for implementing new functions? What advantages does AUTOSAR Classic offer over other architectures in the automotive industry?

One advantage is the wealth of experience built up so far with AUTOSAR Classic. Even though AUTOSAR Adaptive is fundamentally designed for completely different hardware architectures and their requirements, basic procedures from the Classic version can be transferred to development according to the Adaptive standard. Not necessarily copy/paste, since as mentioned there are other requirements, but the basic structure can be transferred. This means that AUTOSAR Classic can also keep up with new functions to a certain extent, even if this is to be understood more in a figurative sense – without AUTOSAR Adaptive, many requirements from the industry would no longer be feasible.

On the second question, AUTOSAR is expected to evolve in the future to meet the requirements of new technologies and industry standards. One example is the integration of 5G connectivity, which will enable it to support more advanced features such as self-driving vehicles. In addition, new applications such as intelligent traffic systems and networked mobility could also be enabled by AUTOSAR.

For example, companies such as BMW or Daimler rely on AUTOSAR-based modules when developing software in the automotive industry. One example is the“AUTOSAR COM Stack” used in the communication between the various ECUs in the vehicle, which is provided by various companies such as Vector or Elektrobit. Another example is the“AUTOSAR Basic Software” developed by Continental, which provides a variety of basic functions such as memory management, drivers and network stacks – this basic layer has to be developed by each manufacturer and thus simplifies interoperability between different development teams of suppliers and OEMs, for example.

Details are dynamic: AUTOSAR Adaptive explained

Compared to AUTOSAR Classic, AUTOSAR Adaptive offers the advantage of an additional service layer that can integrate dynamic functions into the software. For the sake of completeness, the “advantage” is put in quotation marks, since a comparison in this form is not possible at all. Finally, as already elaborated, AUTOSAR Classic and Adaptive simply serve different requirements for different hardware architectures. Nevertheless, AUTOSAR Adaptive allows overall greater flexibility in the implementation of new functions, which is particularly important in future applications such as autonomous vehicles. An example of a dynamic function that can be integrated into Adaptive AUTOSAR is software monitoring of the vehicle’s condition. Continuous monitoring of the vehicle’s condition allows potential problems to be detected at an early stage, resulting in greater safety and reliability, keyword “predictive maintenance“.

AUTOSAR Classic vs Adaptive: The comparison

We have already sufficiently elaborated the major differences between AUTOSAR Classic and AUTOSAR Adaptive in the course, so we will only briefly summarize them again here: The main difference between AUTOSAR Classic and Adaptive lies in their architecture. Both are standardized, but serve different hardware architectures and their requirements, so they usually simply work in different application areas. An example of a dynamic function could be automatic parking for cars, which takes place in real time. Adaptive provides an additional service layer for this and the options to reload or configure applications via UCM during runtime.

Classic is a bit more limited in comparison and can also work with added functions, but not during runtime. In addition, a complete ECU update must always be carried out, whereas UCM (Update and Configuration Management) can also provide individual applications with partial updates.

So although AUTOSAR Adaptive offers more freedom to implement new features, it is also more complex and requires more resources, especially in terms of computing power than Classic. Unfortunately, AUTOSAR (unlike, for example, the well-known ROS aka “Robotic Operating System“) is not taught at universities, so there is also a somewhat higher barrier to entry into the profession here (which is usually in the area of embedded systems engineering ). However, positive mention should be made at this point of the TU Darmstadt, which has changed this and now also teaches AUTOSAR skills.

And now what? AUTOSAR in the future – still hungry?

AUTOSAR has become an indispensable standard in the automotive industry in recent years. The introduction of AUTOSAR Adaptive has improved the flexibility and functionality of the standard and opens up new possibilities for the development of software in the automotive industry. Finally, the increasing networking of vehicles and the integration of autonomous functions are a highly topical trend whose demands on development and its flexibility have increased significantly. AUTOSAR Adaptive was introduced primarily to address precisely these challenges, in order to accelerate the development of intelligent vehicles.

But what does that mean in concrete terms? Companies like BMW and Daimler are already using AUTOSAR-based software modules to ensure their vehicles have the latest and greatest features. BMW, for example, uses AUTOSAR software modules to integrate functions such as autonomous driving, navigation and entertainment into their vehicles. Another example is Daimler AG, which also uses AUTOSAR-based software modules for its electronic control units.

So where does the statement come from, which can certainly be heard in one or the other automotive canteen, that AUTOSAR is a “decades-old standard that has fallen into disuse”? Presumably, such statements come from the pure pressure of innovation, or even little experience with the versatile options of development according to AUTOSAR Adaptive. The standard is not a one-time definition that is now complete. Rather, it is a “living document” that is constantly being developed further – an important task, for example, of the AUTOSAR Consortium and the participating OEMs and suppliers, some of which are also premium partners who are experienced and well networked and sometimes refer to the standard tongue-in-cheek as “continuous AUTOSAR“.

The high level of interoperability, the declared purpose of the standard, its widespread use between vehicle manufacturers and suppliers is also the reason for the current rapid development, in which the traditional German industry is again recording international innovation successes.

Well, admittedly: The introduction of new concepts such as Vehicle API or SOVD (Service Oriented Vehicle Diagnostics) could sometimes be a bit quicker – critics will find a starting point here, but this cannot invalidate any of the points mentioned so far. Thus, AUTOSAR will undoubtedly remain the top dog for software development in the automotive industry in the coming years.

Effects of AUTOSAR on software development

AUTOSAR has fundamentally changed the way software is developed in the automotive industry. Previously, developers had to implement each function from scratch, which was time-consuming and costly. Today, thanks to AUTOSAR, developers can reuse existing functions and implement new ones faster and more efficiently, and they can also better divide development between internal and external project teams, between OEMs and suppliers: all ECUs speak the same language thanks to standardized interfaces and can therefore communicate with each other. This significantly simplifies software development as well as system design and integration – and thus lowers the overall cost of software development. Of course, this is also accompanied by increased maintainability and security, one example being over-the-air updates, which are of immense importance especially in times of UNECER155 and Co.

Let’s go into more detail at this point and cite specific examples in order to establish how elementary AUTOSAR is for industry-wide development standards:

We have established that AUTOSAR has “layers”, i.e. “abstraction layers”, which abstract the specific properties of the hardware platform by means of standardized interfaces. For example, microcontrollers from different manufacturers may have different architectures, which means that software access to the hardware can differ from type to type. However, the implementation of the layers abstracts these specific peculiarities of the hardware, which means that access to the hardware is still individual, but has the same interfaces “upwards”. Applications can now be used and implemented independently of the hardware thanks to this.

A concrete example would be the signal of an input pin (e.g. digital on/off, concerning the detection of the ignition in the vehicle, whether switched on or off). To access the signal, certain register addresses must be called, and these addresses are usually different for each manufacturer. Without the abstraction layers described, each application would have to be completely re-implemented for each different piece of hardware on which it is to run. Thanks to AUTOSAR and its abstraction layers, only the “lowest” layer in each case needs to be adapted – the application itself always remains the same and in this case merely queries a standardized interface. Why AUTOSAR as a standard can save time, costs, resources and development effort is therefore obvious.

By the way, a treatise on AUTOSAR that is definitely worth reading in this context is the publication“AUTOSAR: A Comprehensive Automotive Software Architecture” by M. Bauer and S. Fey, which has a lot to say about the origins and, above all, the future prospects of this interesting standard.

AUTOSAR (Classic and Adaptive): The conclusion (it was bound to happen)

The conclusion is ultimately simple; after all, the most important properties of the AUTOSAR standard have been established and named in detail. Especially in view of the autonomous driving future and, almost more important, the ubiquitous Connected Car, the future viability of AUTOSAR is assured for the time being. Where AUTOSAR Classic is increasingly holding back and leaving the field to its big brother Adaptive, interoperability, communication and functionality are essential development building blocks. Serious alternatives seem thin on the automotive horizon, with theoretical competitors such as Apex.AI and the like playing in fundamentally different leagues and application areas.

In addition, further developments of the standard are conceivable – an example of this is the configuration of AUTOSAR software by manifests (ARXML files). With the basic approach “configuration before implementation”, configurations are largely possible by means of easy-to-use tools instead of having to be implemented directly, as was previously the case. Stack vendors use code generators for this and access a much larger treasure trove of options than before. A model-based development approach and the use of generative A.I. such as “ChatGPT”, which generates the manifests, could still accelerate this approach significantly

If you would like to find out more, we recommend our Embedded section and, closely related to this, interesting topics such as functional security, data protection and machine learning. Have fun and thank you for your attention!