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
- Autonomous Vehicles – Level 3
- EE architectures and the software- defined vehicle
- AUTOSAR and autonomous vehicles
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.
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.
Figure 2 Transfer of control. Source: sbdautomotive.com (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.
Figure 3. Transfer of control HMI. Source: sbdautomotive.com (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.
Figure 4. Projected evolution of in-vehicle electrical architectures. Source: sbdautomotive.com (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.
Figure 5 AUTOSAR Classic Platform. Source: https://www.autosar.org/standards/classic-platform/
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.
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.
Figure 7. AUTOSAR Standards. Source: https://www.autosar.org/
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?