What is AUTOSAR?

AUTOSAR is, how could it be otherwise when it consists exclusively of capital letters, an acronym and stands for “Automotive Open System Architecture“, which translates as an open system architecture in the automotive sector. The classic AUTOSAR covers the current situation in vehicles as a standard : a large number of different ECUs (Electronic Control Units), BUS systems that are primarily structured in a signal-oriented manner, i.e. communicate in an address-oriented manner.

If we give AUTOSAR a Standard we mean that it is a worldwide and jointly formed partnership of various automobile manufacturers (often referred to in the industry as simply OEM, i.e. “Original Equipment Manufacturer” – why this should be viewed somewhat differently in the automotive industry than, for example, with hardware manufacturers in the computer industry is a topic for another article).

This common standard is necessary so that the multitude of systems required in vehicles today, such as software , can be used across different brands, so that safety standards can take effect across the industry, so that partnerships can be formed in development and production, and, of course, in order to strive for sustainability in the product life cycle . For example, the development of an interface that can be used by all manufacturers can be favored, which saves resources and is less time-consuming and less expensive for both manufacturers and customers than before the introduction of AUTOSAR in 2003, when the quantity of different proprietary systems at automotive OEMs tended to become increasingly confusing.

Thanks to AUTOSAR, the very interfaces for communication between the various control units have been standardized, which in turn manage the developer-specific applications (for example, the infotainment system, battery management, engine control, etc.).

With regard to the basic structure, it can be said – in a highly simplified manner – that AUTOSAR Classic is designed in the sense of an architecture in three layers:

• Basic software
• Runtime environment
• Applications

These services run on a micro-controller, and the application software is ideally hardware-independent – this is to be achieved by abstraction through base software and runtime environment, thus increasing portability and reusability. We could go into even more depth, but in favor of a reader-friendly structure, we would refer you to good old Wikipediaat this point.

Compared to the classic AUTOSAR, which covers the situation currently found for the most part on the roads, AUTOSAR Adaptive developed over time and as automotive development progressed.

What is AUTOSAR Adaptive?

The main feature of the AUTOSAR Adaptive Standard is the service-oriented architecture and communication, the necessity of which arises from the multitude of new requirements for current and upcoming vehicles. For example, one focus is on highly automated driving, which requires a vehicle to communicate with numerous off-board applications or take control from the driver completely. From smartphone integration to over-the-air updates, from web services to high computing platforms to process complex tasks in parallel, from cloud backends to remote diagnostics: vehicles evolve, systems and architectures change, and thus standards evolve with them.

Accordingly, the AUTOSAR Adaptive Platform was developed to support an operating system based on the POSIX (Portable Operating System Interface) standard, a common interface developed for Unix between software (the top layer of applications in classic AUTOSAR) and the operating system (the high-performance computing platform).

The core issue is therefore basically simplification: getting away from a multitude of confusing control functions, in whose systemic tangle even professionals sometimes run into difficulties tracing the current function back to the responsible control unit. So it’s moving away from many, specialized, static embedded ECUs to a few, non-specialized, high-performance ECUs that can dynamically configure and distribute functions across domain boundaries. The fact that the industry has been working on this for a long time is also shown by the interesting interview of Mobility Rockstars with the Volkswagen subsidiary CARIAD, which you can find under this link if you are interested.

The declared goal of AUTOSAR Adaptive, a main topic of Cognizant Mobility in the area of embedded systems, which is primarily managed in the Fulda branch under the leadership of Jens Schmidt, is to replace the large number of ECUs and control units with a few, high-performance high computing platforms and cross-domain servers. The long-term vision of Cognizant Mobility, as repeatedly predicted by CEO Jörg Ohlsen, is cross-OEM standardization and communication. “Cross-manufacturer collaborations, as well as IT partnerships along the value chain, make perfect sense for the German automotive industry to keep pace with development requirements on the international market. One of the reasons why I have networked Cognizant Mobility globally with major IT players is to be even better positioned technologically and to be able to help develop standards,” says Ohlsen on the subject of optimal networking.

Especially in the area of AUTOSAR Adaptive, this mindset also results in a derivable, practical benefit – in the future, end users of vehicles could simply receive updates over-the-air while using the vehicle or have them carried out while parked, thus saving them the detour to a workshop. This frees up resources , both at the customer’s end and at the OEM’s or mechanic’s end, which can be invested wisely in the development of future systems.

Of course, this does not mean that everything has already been done and said on the subject of AUTOSAR Adaptive, on the contrary. Development in this area is progressing daily – after all, not only do the appropriate tool landscapes have to be formed and processes defined (a process that is usually not entirely effortless), entire organizational structures have to change, sometimes from the ground up, in order to keep pace with current (software) development requirements. High performance computing systems must be developed that must combine multiple processors, graphics processing units and other processing units – in contrast to AUTOSAR Classic, which is intended for single or maximum multicore architectures. Since many requirements of modern vehicle development also have yet to emerge, Adaptive AUTOSAR must also remain flexible and thus dynamic – again, in contrast to Classic AUTOSAR, which is static in nature and relies on embedded systems.

AUTOSAR Adaptive at Cognizant Mobility

Cognizant Mobility, as part of the automotive industry supply chain, pays a lot of attention to the topic of Adaptive AUTOSAR. For example, the company represents the interests of the Volkswagen Group in the AUTOSAR committee and participates in the development of new standards. Not only being in the front row of this venture, but being an active protagonist in this field shows the experience of the company as well as the confidence of the OEMs.

But active software development below the standard and the development of new software architectures are also part of the tasks of Cognizant Mobility in Fulda, from the concept to the Software development itself, also taking into account other areas of expertise such as cloud services, software as a service and embedded systems – in other words, everything that is “embedded” in the vehicle in terms of software.

The next step in the further development of both the AUTOSAR standard and in-house expertise is to build a demonstrator that clearly shows how Adaptive AUTOSAR can be used, how ideas and concepts can be developed, but also how problems can be tested. For this purpose, Cognizant Mobility is working with an Adaptive AUTOSAR software stack as part of a customer order. How exactly this works from a technical point of view is explained in an exemplary way in a comprehensive dossier from the University of Koblenz Landau, which we are happy to link to you here.

This stack is an excellent way to map and explore innovations and current developments, using a highly dynamic software environment and multiple virtual instances that mimic ECUs and help to move away from a multitude of ECUs to the use of fewer high-performance computing platforms. This allows us not only to draw logical conclusions regarding new possibilities, but also to test concepts and architectures that can be incorporated into the Adaptive AUTOSAR standard.

Taking this one step further is a physical demonstrator, such as an HPC platform running AUTOSAR Adaptive and communicating with, for example, an automotive Android device or a Classic platform. A conceivable use case would be updating the non-adaptive components in the vehicle or consuming an off-board service.

This not only serves to promote the own know-how : It also makes it possible to conduct AUTOSAR or embedded system training courses . Using this demonstrator at trade fairs and presenting it directly to customers are current goals of the Adaptive AUTOSAR activities. Away from the usually little concrete attempts at explanation, which all too often remain vague and purely conceptual. Concrete user stories can be mapped on a physical demonstrator – how is an app installed via plug and play, how are ultra wideband systems connected, or how can personalized changes be transmitted over the air across different locations, keyword “digital twin“?

The benefits of AUTOSAR Adaptive- The conclusion

It is not difficult to name the pure benefit factor of common standards : simplification, overarching collaboration, faster and more efficient development. As computing demands become more intensive, systems and architectures must keep pace. Adaptive AUTOSAR provides a foundation for the increasingly rapid pace of development by maximizing the ability to update and upgrade required components. Especially in the field of autonomous driving functions, enormous computing power is required, as well as architectures that evolve dynamically and can quickly and flexibly meet modern and sometimes changing requirements. The move towards service-oriented architecture enables joint progress in a market that has long – perhaps almost too long – been developer-specific.