Designing Ultra-Low Power Application Using Standardized AUTOSAR ModulesDesigning Ultra-Low Power Application Using Standardized AUTOSAR Modules

The Surge of ECUs and the Transition to New EE Architecture in Automotive Applications

Rakesh Kumar Rajakumar, Principal software engineer for Microchip Technology's automotive products group

December 2, 2024

11 Min Read
The zonal architecture employed in the Rivian R1 2.0 vehicles.
The zonal architecture employed in the Rivian R1 2.0 vehicles.Rivian

The automotive industry has experienced significant changes in recent years due to electrification and the growing demand for enhanced safety, comfort, and luxury features. In today’s high-end vehicles, it is common to find 150 to 200 Electronic Control Units (ECUs).

The increase in ECUs has also driven the need to reduce complexity and weight in electric vehicles (EVs), prompting shifts in vehicle Electrical and Electronic (EE) architecture. This has led to the transition from traditional domain controller architecture to zonal architecture. Zonal architecture simplifies the vehicle's EE system by centralizing complex computation in a central computer, while edge nodes handle less-demanding tasks.

Historically, ECU software was rarely updated after production, except to address major issues. However, with the advent of zonal architecture and Software-Defined Vehicles (SDVs), features like Over-the-Air updates enable continuous software enhancements and new feature additions even after the vehicle is on the road. This marks a shift toward the ongoing evolution of ECU systems, extending their development beyond initial production.

Autosar_fig_1.jpg

AUTOSAR: The Language of ECU Software Development

AUTOSAR is a global consortium created to address the increasing complexity of electrical and electronic (EE) systems, shorten ECU software development lifecycles, and enhance reusability and scalability in the automotive industry. The working group developed the AUTOSAR software architecture and module specifications to standardize ECU software development. Today, the AUTOSAR consortium plays a pivotal role in shaping nearly all new automotive technologies. Many OEMs are encouraging their suppliers to adopt the AUTOSAR software architecture for ECU design due to its many advantages, including scalability, flexibility, standardized toolchains and methodologies, interoperability, and a unified software architecture.

Related:Why Cars Are Migrating to Zonal Electric Architecture

While this article focuses on the AUTOSAR Classic platform, AUTOSAR has also expanded to System-on-Chip (SoC) applications with AUTOSAR Adaptive.

The Importance of the Microcontroller Abstraction Layer (MCAL)

One of the key benefits of the AUTOSAR software architecture is the standardization of the underlying hardware abstraction layer, known as the MicroController Abstraction Layer (MCAL). This layer defines the software requirements and feature set for the driver components that interface directly with microcontroller (MCU) hardware peripherals. MCALs are generally categorized into four main types.

Related:New ECU Architectures, Open-Source Initiatives Shift SDVs Into Overdrive

Microcontroller Drivers

MCU (For Clock Schema)

WDG (Watchdog)

GPT (Timers)

Memory Drivers

FLS (Flash)

Communication drivers

SPI (SPI Driver)

LIN (Lin Driver)

CAN (Can Controller)

ETH (Ethernet)

I/O Drivers

ICU (Input waveform Capture)

PWM (Pulse Width Modulation)

ADC (Analog to Digital Converter)

DIO (GPIO PIN Control

PORT (Port Control)

MCAL provides standardized interfaces to the higher layers of the software stack, making the application platform-independent and enabling easier porting of the application layer to different MCUs. This standardization reduces software development time and costs while improving maintainability, as the effort to create and validate MCALs is shared across multiple projects and organizations.

Need for Ultra Low Power Automotive Applications

In modern cars, the power requirements have risen significantly due to the complexity and number of ECUs across various domains such as infotainment, advanced driver-assistance systems (ADAS), chassis, body and electric drivetrains. A vehicle’s power demand can spike during active phases compared to idle states.

Autosar_fig_2.jpg

An increase in the number of ECUs increases the power consumption during operation, which affects the fuel consumption or range in the case of EVs. ECUs must be power efficient even when the vehicle is in a running state. This is in contrast to previous generations of cars where low power was a requirement only while the ECUs were in sleep mode. This has pushed automakers to focus on refining power consumption by merging ECUs to reduce overall power needs, enhancing the efficiency of individual units, and implementing intelligent power management strategies that minimize standby and leakage currents.

Related:FPGA Software Solutions Ease Time-to-Market for Automobile Apps

The zonal architecture enables the use of multiple edge nodes that do not require complex computation but need to connect to the central ECU through communication channels. With the increasing number of ECUs, it is essential to make them power-efficient to reduce overall power consumption in EVs. Besides edge nodes, many automotive applications also require low power consumption including:

  • Battery-operated applications: Tire pressure monitoring system, keyless entry systems.

  • Systems operating when the engine is turned off: Kick sensors for boot operation, touch door handle sensors to unlock the door, steering wheel switch to operate Infotainment systems.

8-bit MCUs the Optimal Choice for Automotive Ultra-Low Power Applications

The choice of MCU in a node is crucial in determining the overall power consumption of the ECU. For edge nodes and battery-operated ECUs, 8-bit MCUs are an optimal option because they are designed to operate with minimal power during active states and overall simpler devices with lower processing capabilities.

A typical 8-bit MCU operates at lower clock speeds, in the 8 to 16 MHz range, which results in fewer switching events per second and, results in reduced energy usage. During sleep mode, 8-bit MCUs exhibit minimal anode leakage current, which significantly reduces sleep current consumption. The sleep current values are much lower when compared to 32-bit MCUs and this gap widens significantly while operating at higher temperatures such as in automotive applications.

Another factor contributing to reduced power consumption in 8-bit MCUs is the MCU architecture itself. A typical RISC architecture machine with simplified instruction set will consume less. An 8-bit Harvard RISC MCU has separate data and address buses, enabling simultaneous access to instructions and data, which reduces the time spent in an active state.

Apart from the above advantages, the 8-bit microcontrollers come with a variety of features:

  • Core Independent Peripherals: CIPs autonomously handle tasks using hardware-defined interrupts, reducing CPU involvement, power consumption and latency. They simplify tasks that usually need complex interrupt service routines, speeding up development and making application design more efficient.

  • Intelligent clocking: This feature allows for selective activation of peripherals, minimizing power drawn when certain functions or peripherals are not in use, while also scaling the required computing power to the application's needs instantaneously.

  • Multiple low power modes: A variety of low-power mode options offer flexibility to select power modes based on the state of the ECU, such as Active, Idle, Standby, Extended Standby, Wait, and Power Down.

The collective benefits of low power consumption during operation, minimal sleep current, multiple low-power modes and adequate processing power, puts 8-bit MCUs as an optimal choice for automotive low-power applications.

Opportunities and Considerations for Implementing AUTOSAR in 8-bit MCUs

8-bit microcontrollers (MCUs) are optimized for applications with smaller memory needs and lower processing requirements, making them highly efficient for simpler tasks. While their compact memory footprint is ideal for power-sensitive designs, integrating the AUTOSAR software architecture can introduce challenges due to its larger memory demands compared to custom software tailored for specific end uses. For instance, the RAM memory requirements for the AUTOSAR stack—especially when incorporating communication protocols like Ethernet—can be significantly higher.

Despite this, the benefits of AUTOSAR, such as streamlined software development and enhanced scalability, are substantial. By carefully balancing the power efficiency of 8-bit MCUs with the advantages of AUTOSAR’s architecture, it is possible to harness the strengths of both. With thoughtful design choices, 8-bit MCUs can still play a key role in delivering power-efficient ECUs without sacrificing the innovation that AUTOSAR brings to the table.

Adapting AUTOSAR in Low Memory 8-bit MCUs

To leverage the advantage of AUTOSAR architecture and the related methodologies in 8-bit MCUs, a solution is to bypass the AUTOSAR Software Stack and use only the MCAL layer with a simple scheduler instead of a full-fledged OS. To implement this concept, one must have deep knowledge of AUTOSAR BSW layers and their interfaces.

There are three major types of interfaces specified by AUTOSAR.

AUTOSAR Interface

“AUTOSAR Interface” specifies the data exchanged between software components and/or Basic Software (BSW) modules. These interfaces are utilized to define the ports of software components and/or BSW modules.

e.g., communication between the application and BSW, or among Application Software Components (SWCs)

Standardized AUTOSAR Interfaces

A "Standardized AUTOSAR Interface" refers to an "AUTOSAR Interface" with syntax and semantics that are standardized within the AUTOSAR framework. These interfaces are commonly employed to define AUTOSAR services, which are standardized services offered by the AUTOSAR Basic Software to application software components.

e.g., services for AUTOSAR OS

Standardized Interface

A "Standardized Interface" refers to an API that is standardized within AUTOSAR without employing the "AUTOSAR Interface" method. These standardized interfaces are generally utilized between software modules that reside on the same ECU.

e.g., APIs in Microcontroller Abstraction Layers (MCALs)

Autosar_fig_3.jpg

The ‘standardized interfaces' for each MCAL component are defined by the AUTOSAR architecture, specifying both the API names and structure (including the API parameters). For example, ‘Mip_Init()’ is the ‘standardized interface’ specified by AUTOSAR for initialization of each MCAL module. Instead of ECUM Module calling this ‘standardized interface’ in a typical AUTOSAR software architecture, here in this case, a proprietary software responsible for state management can directly invoke this interface to initialize the MCAL module. For cases related to sleep/wakeup management, ‘Mip_SetMode()’, ‘Mip_CheckWakeup()’ standard interfaces are available in the MCAL driver.

Since the RTE is not present in this design, the OS interfaces are directly invoked within the SWC/proprietary software. To facilitate standardization, a minimalist OS with co-operative scheduling can be developed with AUTOSAR OS-like standardized interfaces. This will provide mechanisms such as schedule tables, counters/ticks for timeout calculations, and locks for SWCs. The specifications for MCAL and AUTOSAR OS are accessible to members of the AUTOSAR consortium. Tier1s and OEMs can upgrade their existing OS to align with AUTOSAR-like interfaces, though it is not necessary to comply strictly with the mechanisms outlined in the AUTOSAR specifications. This step is optional and intended to further align with the AUTOSAR software architecture.

Autosar_fig_4a.jpg

Autosar_fig_4b.jpg

Benefits of Implementing AUTOSAR for Small Memory Footprint MCUs

The full advantage of AUTOSAR is realized through the use of a standardized toolchain defined by AUTOSAR. Many tool vendors have developed configuration tools according to the AUTOSAR  specifications, which can be purchased and used by ECU developers. Teams with prior AUTOSAR experience are familiar with these standard tools, making the process more efficient. This tool provides all the possible configurations that can be selected by the end user to configure the MCAL modules according to the end application requirement, eliminating the need for hand coding. The complete ECU configuration can be saved and shared as *.ARXML files. This standardization facilitates the reuse of configurations and strategies across different projects, promoting consistency and efficiency in the Software Development Life Cycle (SDLC) across Tier 1s and OEMs.

This approach ensures that organizations can train engineers on similar tools used across various projects, regardless of whether the project fully adheres to AUTOSAR standards. Consequently, the development team does not require separate training or specialized skills to understand this streamlined version of the AUTOSAR software architecture. This will enable organizations to create applications that are more abstract than traditional ones. Additionally, MCALs can be directly purchased from semiconductor vendors, providing organizations with the advantage of negotiating for better deals.

AUTOSAR vs BSP (Board-Support-Package)

Automotive ECU software development requires significant development, integration and validation efforts. AUTOSAR decouples the software and hardware developments, which results in reduced software development times.

Autosar_fig_5.jpg

The different approaches to achieve low power during operation such as partial networking, partial ECU degradation are specified in the AUTOSAR MCAL driver. These features are highly unlikely to be supported by the standard BSP packages supplied by the MCU vendor.

For example:

  • MCALs have standardized Interfaces for de-initialization, re-initialization and re-configuration of drivers to achieve ECU degradation technique. 

  • Communication MCALs provide ‘Mip_CheckWakeup()’ API to implement configurable wakeup patterns.

  • MCALs has ‘Mip_SetMode()’ API, which can be used to selectively put peripherals into low power modes.

AUTOSAR modules are designed to be compiler-independent, unlike typical BSPs from semiconductor vendors, which may not be compatible with third-party compilers. Also, MCALs are designed with safety and quality, developed to comply with automotive software development life cycle like Automotive SPICE and ISO26262 (automotive functional safety standard).

Summary

The evolving Automotive EE Architecture underscores the increasing complexity of vehicle electronics and the demand for energy-efficient solutions. The reduced current consumption and optimized design of 8-bit microcontrollers render them highly desirable for applications that do not necessitate intensive computation. With the focus on edge nodes, the ECU will not be required to perform complex tasks during operation. Consequently, the implementation of proprietary software should be minimal. The use of ‘standardized interfaces’ ensures that proprietary application components remain interoperable. This means that once developed, these components will require minimal modifications to be reused across different platforms or hardware.

Integrating 8-bit MCUs into automotive edge node applications enhances functionality and improves overall vehicle efficiency and sustainability, aligning with the industry's shift toward more electrified and connected vehicles. The adoption of AUTOSAR architecture in low-power ECU development, along with standardized toolchains, helps reduce development costs and timelines, enabling the development of power-efficient ECUs.

About the Author

Rakesh Kumar Rajakumar

Principal software engineer for Microchip Technology's automotive products group, Microchip Technology

Sign up for Design News newsletters

You May Also Like