AUTOSAR has become ubiquitous in the development of automotive ECUs, but its role may change as new and more complex autonomous vehicle technologies come to market. By Martin Howle and Alain Dunoyer

AUTOSAR has become ubiquitous in the development of automotive ECUs at many OEMs, but as new and more complex autonomous vehicle technologies come to market what role will AUTOSAR play?

Autonomous Vehicles – Level 3

We have entered the era of cars needing less driver support as autonomous systems become more capable, but for the foreseeable future, they will still need a driver as a backup (e.g. SAE Level 3, figure 1). The Level 3 systems, Conditional Driving Automation, will only work under certain conditions and in certain locations, therefore, for much of the time the vehicle will need to be controlled by the driver and only when all of the conditions are met can the vehicle take control of the driving task. As such there needs to be a transfer of control between the vehicle and driver and vice versa throughout the journey.

autosar is the backbone of avs and adas, but for how long?

Figure 1. SAE levels of automation

SAE Level 3 will be a huge step for vehicle manufacturers (the level of robustness that will need to be demonstrated is similar to civil aviation standards). Humans are adaptable and can generally work around poor controls and instructions. But, when a Level 3 vehicle is fully in control, it is no longer the driver that needs to adapt to the limitations of the vehicle. The vehicle needs to adapt to the limitations of its driver—any driver. If the vehicle decides it needs to hand over control to the driver, it must be capable of conveying that quickly, robustly, and clearly.

So, how does a Level 3 vehicle safely transfer the control of the driving task between the vehicle and driver?

There are a number of aspects to the transfer of control (figure 2):

Driver to vehicle:

  • The vehicle must make the driver aware that the required conditions are met and that the vehicle can drive autonomously, if required
  • The driver must inform the vehicle that they wish the vehicle to take control
  • The vehicle must take control and reliably inform the driver that it has control
  • Once in control, the vehicle must continuously monitor the driver to ensure that the driver is capable of re-taking control if required.

Vehicle to driver:

  • The vehicle must initiate a transfer of control procedure if:
    • The vehicle is unable to maintain control (emergency transfer)
    • The driver is not responding to the driver monitoring system
    • The conditions required for the system are no longer being met
  • The driver must take control of the vehicle if requested
  • Standard transfer of control—in a controlled procedure over a 30-60 second window, depending on implementation
  • Emergency transfer of control—The driver needs to take control due to emergency conditions, for most systems this would be a minimum of 5-10 seconds
  • If the driver does not take control or respond to the driver monitoring system the vehicle will fall back to its safe state, in most cases this will result in the vehicle stopping in lane and initiating an emergency call.

autosar is the backbone of avs and adas, but for how long?

Figure 2 Transfer of control. Source: (Driver and Cabin Monitoring – report 810)

This transfer of control needs to be managed between the vehicle and the driver using the Human Machine Interface (HMI). The in-vehicle HMI systems include touchscreens, displays, switches, buttons, audio, voice and haptic. The system design must be carefully considered to ensure the required functional safety requirements are met, especially when incorporating audio and infotainment systems that traditionally do not support Automotive Safety Integrity Level (ASIL) requirements.

In most cases there will be a combination of visual HMI using the various available displays, audio feedback in the format of chimes or possibly voice commands, haptic feedback through seat or steering wheel actuators, and steering wheel buttons and switches for driver input (figure 3). Using multiple HMI systems ensures redundancy and enables decomposition of functional safety requirements from a higher ASIL–D rating to a lower ASIL–B/A, reducing the impact of the design changes on the individual systems, and increasing the likelihood of driver engagement if they are distracted from the displays or possibly hard of hearing or even deaf, meaning that the audio feedback is never heard.

autosar is the backbone of avs and adas, but for how long?

Figure 3. Transfer of control HMI. Source: (Driver and Cabin Monitoring – report 810)

The overall system design for a Level 3 system, as might be expected, will incorporate a number of sensor and smart sensors, ECUs and actuators in the motion control, body, and AV/ADAS domains, but also due to the transfer of control requirements this will now have an impact on the audio and infotainment domains too. This leads to a highly complex overall system design across multiple domains and ECUs, from different Tier 1 suppliers to deliver Level 3 autonomous driving system that will have ASIL-D functional safety requirements. Using AUTOSAR can help to alleviate some of the development headaches by providing a common software architecture framework.

EE architectures and the software- defined vehicle

Another significant trend is that as electronic hardware and software become more capable, there is consolidation of technologies across multiple domains into a smaller number of more complex, multifunction ECUs. EE architectures are moving from functional-orientated ECUs  to more complex functional domain controllers, and in the future on toward centralised and zonal architectures (figure 4). This will eventually allow fully scalable service-orientated architectures, achieving what many are calling the software defined car, in other words, a vehicle for which the majority of its functionality is built on hardware-agnostic software platforms. This concept allows manufacturers to develop software independent of its various hardware configurations while exercising the benefits of updatable vehicle platforms in production.

To achieve this, most manufacturers are scaling up internal software development teams to manage the vehicle’s software product roadmap, as opposed to outsourced partners or Tier 1s. In most cases, the Tier 1s will still deliver the hardware and software components, but the ownership of the system will be with the OEMs. They will have to integrate these complex systems with components from multiple suppliers. Using the AUTOSAR framework allows the OEM to define portable software components and the communication interfaces between them. This can help with the difficult system integration and debugging tasks, and will mean that many software components can be reused as EE architectures evolve.

autosar is the backbone of avs and adas, but for how long?

Figure 4. Projected evolution of in-vehicle electrical architectures. Source: (EE Architecture Platforms – report 630)

AUTomotive Open System Architecture (AUTOSAR) is a development partnership of automotive OEMs, tier 1s, and technology developers founded in 2003 to create an open standardised software architecture for automotive ECUs. The architecture defines standard software modules and service interfaces to provide hardware independence by encapsulating software components (figure 5). The first release of the platform was back in May 2006 and the first implementation of AUTOSAR technology was launched into market in 2008.

autosar is the backbone of avs and adas, but for how long?

Figure 5 AUTOSAR Classic Platform. Source:

The initial platform was targeted at microcontroller-based ECUs providing single functions and has gained significant market penetration since its introduction with most automotive OEMs now partnering with the AUTOSAR organisation.

As automotive system complexity has increased there has been a move from simple single function ECUs based on microcontrollers to more complex multiple function ECUs based on microprocessors. This requires a more developed software architecture that supports advanced features such as  connectivity, time synchronisation, cyber security, V2X, SOTA, etc.

In response to this AUTOSAR developed the Adaptive platform (figure 6), providing a POSIX-based operating system designed to run on multicore SoCs. The original platform was renamed as Classic, and the shared low level requirements and specifications were placed into a Foundation standard.

autosar is the backbone of avs and adas, but for how long?

Figure 6. AUTOSAR Adaptive Platform

The first release of the Adaptive Platform was in March 2017 and now both platforms co-exist and complement each other. The Adaptive Platform is not seen as a replacement to the Classic Platform; they have different attributes and are suited to different implementations. The complete framework also includes Acceptance Testing allowing for system validation, and standard Application Interfaces between defined domains supporting greater software reuse and exchangeability (figure 7). ECUs within the same system can run either platform and still make use of the ECU interoperability offered by AUTOSAR communication features.

autosar is the backbone of avs and adas, but for how long?

Figure 7. AUTOSAR Standards. Source:

AUTOSAR and autonomous vehicles

AUTOSAR Classic Platform has been used in many Level 1 and Level 2 ADAS systems that are in market today, often on single feature ECUs such as ACC, AEB and LKA. AUTOSAR Adaptive is now beginning to be used in more advanced ADAS features with the software processing implemented in high performance computing platforms.

Many OEMs mandate the use of AUTOSAR on their ECUs especially to manage vehicle communication networks across CAN/Flexray/LIN/Ethernet. This is often driven by the OEMs’ need to own and manage their networks. The ECU configurations and message catalogues can be released to numerous Tier 1s in a controlled manner, and the use of the AUTOSAR ECU configuration file (ARXML) to achieve this is widespread. Although some ECUs can be exempt from this requirement if it is not fully suited to their function.

As we move toward more complex vehicle systems including autonomous vehicle systems it is clear that AUTOSAR will have a role to play in many OEMs. The systems implementing Level 3 autonomous features will involve multiple ECUs across many domains and the ECU interoperability, end to end (E2E) functional safe messaging protocols, software portability and functional safety features make developing within the AUTOSAR framework the obvious choice. This will also ease the transition of the traditionally non-functionally safe HMI systems, enabling the transfer of control aspects to meet their functional safety requirements by expanding the AUTOSAR features that they already support.

Having said all of this AUTOSAR will only be providing some of the software layers within the systems. Whilst they have somewhat of a monopoly on vehicle networking, the Adaptive Platform might not be the major choice for implementing complex autonomous features and there are many other software systems, both proprietary and open source available, including OpenCL, Robot Operating System (ROS), and Mobileye, etc. Fortunately for developers and AUTOSAR, systems can be built with the best of both worlds using the AUTOSAR stack for communications and safety critical fall back but using middleware such as SOME/IP and DDS to link to other higher level systems.

It is safe to say that for the moment AUTOSAR provides a backbone for AV/ADAS and many other systems within the vehicle. However, it is part of an ever evolving ecosystem involving many other software systems, and as greater levels of autonomy develop on more centralised and zonal-based architectures, the exact role of AUTOSAR is yet to be determined.

About the authors: Martin Howle is Domain Principle, EE Architecture, at SBD Automotive. Alain Dunoyer is Knowledge & Talent Director at SBD Automotive

Keyword: AUTOSAR is the backbone of AVs and ADAS, but for how long?


As Baidu announces L5 driverless permits, the conversation about functional safety grows

How is ISO 26262 factored into autonomous vehicles? By Elle Farrell-Kingsley

View more: As Baidu announces L5 driverless permits, the conversation about functional safety grows

Can Europe’s aerospace capital reinvent itself as a future mobility hub?

Toulouse is positioning itself as a centre for mobility talent, investment and innovation, writes Megan Lampinen

View more: Can Europe’s aerospace capital reinvent itself as a future mobility hub?

How can driving dynamics keep up with the autonomous, electric revolution?

Simulation allows engineers to see how motion control capabilities will behave in increasingly complex vehicle architectures. By Christophe Bianchi

View more: How can driving dynamics keep up with the autonomous, electric revolution?

An inside look at the UK’s Automated Vehicles Act

The UK is pushing ahead with revolutionary proposals to promote autonomous vehicles. By Paul Kirkpatrick The Law Commission for England and Wales and the Scottish Law Commission recently unveiled proposals for the creation of a revolutionary new Automated Vehicles Act. The proposals seek to regulate vehicles which are capable of ...

View more: An inside look at the UK’s Automated Vehicles Act

Liability rules threaten autonomous truck uptake

Alletta Brenner explores how existing liability rules could affect the speed and manner in which driverless trucks are adopted Truck driver shortages are one of the leading reasons for recent supply chain woes but the issue is hardly new. Lack of drivers has been the top-rated problem affecting heavy trucking ...

View more: Liability rules threaten autonomous truck uptake

Regulation of self-driving vehicles: the recommendations of the Law Commissions

Chris Heitzman outlines the Law Commission’s final recommendations for AV law changes and how this could impact fleet managers keen on automatising their fleet On the 26 January 2022, the Law Commission and Scottish Law Commission published their final report making recommendations for the safe and responsible introduction of self-driving ...

View more: Regulation of self-driving vehicles: the recommendations of the Law Commissions

Managing Volatility: The race to conquer an uncertain future in the CV industry

Megatrend development is enacting a profound change on the commercial vehicle sector, writes Roland Berger’s Wilfried Aulbur, Walter Rentzsch, Frank Pietras and Wenbo Yuan The transportation industry has seen solid growth over the last 20 years. Markets like the EU and North America have seen a CAGR of 3.8% during ...

View more: Managing Volatility: The race to conquer an uncertain future in the CV industry

A common language and best practice key to AV development success

With numerous players developing a wide range of automated driving systems, how can the industry get everyone on the same page? By Megan Lampinen Automated and autonomous driving developments are gaining pace, with an increasing number of pilots making their way to public roads. But as innovation picks up, a ...

View more: A common language and best practice key to AV development success

What does 2022 hold for the AV market?

What does sensor fusion mean for the future of radar?

Location data: the keystone of the software-defined car 

Driverless shouldn’t equal meaningless: creatives can unlock the user experience 

Does the future of the automotive industry look secure? 

State—not federal—policy guides US autonomous driving

Subjective attribute engineering vital to ADAS and autonomous development

The cyber security catch: the joys of connected cars comes with a caution

Join the Team-BHP Meet & Food donation drive

Los Angeles gets the first electric fire truck in America

Elon Musk’s 'antics' turn owners, would-be buyers against Tesla

Hyundai may build EV plant in Georgia


Breaking thailand news, thai news, thailand news Verified News Story Network