Berlin, June 2023. You’ve got an appointment on the other side of the city at 8.30 a.m. Via an app you hail an autonomous Citypilot that gives you a ride to your office. Today you chose a more expensive private taxi service where there is no ride-sharing with other passengers to save costs. On the go you find out about the current stock prices, the news and the weather forecast with the help of the infotainment system of your vehicle. In the background your car communicates with all the other autonomous cars on the road, as well as with the street signs, the traffic lights and hundreds of other sensors that help to keep the traffic going smoothly. Your car is sending and receiving data regarding the conditions of the road and of its motor, the time management, it is logging data about the driven kilometers and the electricity it has used. All this is working under the hood and does not require your input as a passenger due to the embedded software architecture that makes this kind of automation possible.

The excerpt of a day above is not as fictional as it may seem. Autonomous cars are becoming normal in our everyday life, entire industries are shifting their business models towards autonomous transportation. The megatrends of digitalization have arrived in every aspect of our daily lives. In automotive, topics such as connectivity, electrification and automated driving are of utmost importance. According to a study of the Prognos Forschungsinstitut for the ADAC the share of self-driving cars on the road is going to rise to approximately 40 percent. Furthermore, new competitors, who are developing new applications and software solutions, are entering the market. In addition to the challenges of the technological changes, this poses a threat to the original equipment manufacturers (OEMs) and suppliers. Arising from this competitive pressure, new applications are being developed that offer advantages to both, customer and manufacturers. But a successful and efficient development of those applications cannot be achieved using the current architectures. 

To create a new kind of electric/electronic (E/E) architecture a development partnership between OEMs, tool developer, and supplier have been developing a new standardized automotive software architecture for the past 15 years. The result of this endeavor is AUTOSAR (AUTomotive Open System ARchitecture)

What does that mean? The goal of AUTOSAR is to standardize the software architecture of electronic control units (ECUs) based on the motto „cooperate on standards, compete on implementations“. AUTOSAR enables a common development methodology based on a standardized exchange format. This means that software which has been developed for the AUTOSAR layered software architecture can be used in cars made by different manufacturers and ECUs of different suppliers can be used by all participating OEM’s. In doing so, AUTOSAR is leading the way to innovative systems that provide better performance, security and improved environmental compatibility..

In modern Automobiles the interconnectedness of electronic components is rising fast. Safety, Infotainment, automated sensor technology, Vehicle-to-X-communication and many more areas of application require specialized ECUs. Therefore, the goal of the first AUTOSAR Version Classic 1.0 (2005) was to curb the constant redevelopment of identical or similar software components. A crucial element of this development was the virtual function bus (VFB). This virtual bus decouples the application from the infrastructure. The VFB thus handles both the communication within, as well as between the individual ECUs. This approach has proven itself to be groundbreaking: Today, around 70 percent of all ECUs are configured according to the AUTOSAR standard. However, with AUTOSAR Classic all applications have been restricted to certain electronic control units and the architecture turned out to be too rigid to meet the ever-evolving technical standards of the modern car.

The increased complexity resulting from the growing amount of data from new sensors lead to a trend of task sharing and dynamic systems. While in the past it was sufficient for one ECU to perform one control function, today the trend is for one ECU to perform several functions. That is because computationally intensive algorithms, more powerful processors, and an ever-increasing connectedness in networks of transportation make a dynamic, flexible software architecture necessary. This is where the AUTOSAR Adaptive Platform comes into play, which has been developing since 2017. In contrast to the Classic Platform, Adaptive offers several innovations: For example, subsequent changes to applications (e.g. in form of updates) or the import of newly developed applications via a wireless interface such as WLAN or the mobile network (meaning so-called over-the-air updates) are made possible. And while Classic’s primary focus was on ECUs that had to access directly to specific sensors and drive elements, the Adaptive Platform targets applications with great performance requirements as for example the highly automated driving. However, AUTOSAR remains interoperable and will distribute software functions between ECUs, each equipped with the Adaptive or Classic platform, depending on the software feature's requirements. Computing intensive functions will be located in Adaptive ECUs, deeply embedded functions in Classic ECUs. Another key feature of the Adaptive Platform is service-oriented communication. The core of the new Adaptive Platform is an operating system based on the POSIX (Portable Operating System Interface) standard.

At the beginning of November, the next major Update for the AUTOSAR Adaptive Platform has been released: Adaptive Platform 18-10. AUTOSAR 18-10 adds new function clusters and associated Application Programming Interfaces (APIs) to the Adaptive Architecture. These give application developers the ability to leverage basic services provided by the architecture (for example, to search for a service in the vehicle or to offer a service to others via ara::com). These basic services will be supplemented with each release in the future.

Integrated E/E architectures in the auto industry should be absolutely reliable and able to perform their tasks without errors. Fraunhofer FOKUS and the business unit Quality Engineering (SQC) are premium partners of the AUTOSAR development partnership and are helping developing the standard further. The increasing complexity of embedded systems and architectures are setting particularly high demands on the development skills of the engineers today. Through the use of modern methods and efficient development tools as well as by cooperating with different teams, the scientists of FOKUS and their AUTOSAR partners are able to carry out complex system developments efficiently, reliably and in accordance to the standards.

Specifically, this work results in various application areas, especially in the AUTOSAR working group that deals with the methodology and exchange formats.

In the ecosystem of the Adaptive Platform, Fraunhofer FOKUS is involved in creating a format for a manifest. Together with the application, this manifest is loaded on the control unit and contains in addition to the configuration of the applications further configurative settings that are necessary to enable the execution of the system.

An application manifest specifies, among other things:

• When the application should be started (e.g. in which state of the vehicle)
  
• How often
  
• The application is supposed to start
  
• How to start the application (with which input parameters)
  

The manifest is being downloaded directly onto the controller. The exchange format used for this purpose is XML. Developers can now set up the application they have designed on top of the standardized interfaces of the newly developed APIs. This standardization also makes it possible for applications from different manufacturers to be packed on one control unit, all of which use the standardized AUTOSAR interface.

That means, if an application is looking for a service (e.g. a gas station nearby), it uses the standardized ara::com API and the FindService method. The same applies to a program that displays a service for, say, the outside temperature. Again, FindService would be called up to get all the services that can provide an outside temperature. This configuration is evaluated at runtime and the execution of the system is controlled according to the configuration without having to adjust the applications.

This is the dynamic and flexibility that distinguishes the Adaptive AUTOSAR Platform from other architectures.

To make the day described at the outset possible, all electronic control units must function properly. The failure of just a few ECUs can lead to serious accidents in a highly networked, complex system such as road traffic. A well-designed and tested system architecture is a prerequisite for the proper functionality of this system. In the future, further development of functions and the growth of a flexible work-package-structure will be the focus of efforts. AUTOSAR has already become a cross-market standard in the automotive industry and will continue to form the basis for a successful integration of automotive electronics in the future.