Historically, designers added MCUs to vehicle designs where sensors or actuators required more intelligence, creating a need for more complex control or communication. But combining the additional complexity of options within different vehicle platforms resulted in complex vehicle system descriptions, high development effort and challenging maintenance. For example, over-the-air updates required testing against all configurations, adding significant time and complexity to the process.

To help solve the challenges of complexity, weight and cost, domain and zone control architectural concepts have emerged. Take a look at what these different architectures require of the subsystems within a vehicle.

In a domain architecture, each domain accumulates certain electronic control units (ECUs) based on related function. As an example, the onboard charger, DC/DC converters, traction inverter and BMS would encompass the HEV/EV control domain and share a single, centralized MCU, as shown in Figure 1. This reduces the number of distributed MCUs, puts functions in proximity to simplify interfacing, and enables the sharing of computing resources by centralizing identical functions into a single MCU. For example, the OBC and inverter would not be operating the same time and would instead share computing capacity.

Zone architecture takes the idea of domain control one step further, with functions grouped into zones and controlled by MCUs based on the location in the vehicle, as shown in Figure 1. The zones are connected through a high-bandwidth communication backbone, since distributed sensors and actuators among zones require timely communication. While reducing the number of required MCUs, zone architecture reduces wiring harness complexity and weight, resulting in further cost savings and increased driving ranges. Hardware and software update cycles are decoupled and automakers can move to a service-based software structure.

While domain and zone architectures have different advantages and challenges, they can also coexist in the same vehicle within a crossover architecture. For example, the BMS can use a domain control approach while automated driver assistance systems (ADAS) leverages zone at the same time. The transformation of powertrain to domain or zone control architectures often happens later, after addressing application-specific challenges in the areas of functional safety and system agility. Following the original philosophy to centralize MCU functions as much as possible means that the BMS must communicate through sophisticated or standardized interfaces with no MCU intelligence at the edge. This type of implementation meets the goal to reduce the number of MCUs.

However, a technical challenge then arises: cell or pack high-voltage chipset data (voltage, current and temperature readings and related safety measures) will transfer as raw data. Since fault detection time interval, fault reaction time interval and safe states are tightly defined, the available bandwidth of the interface needs close observation and optimization and the zone- or domain-controlling MCU requires tight time-slotting to process within a given time interval. Figure 3 compares embedded system architectures within the BMS.

Equipping the high-voltage chipset with more intelligence or adding a smaller safety MCU at the edge of the BMS, such as in a smart battery junction box, simplifies this challenge.. By locally addressing functional safety measures, no data except tasks will transmit within the BMS – the local safety MCU at the edge transmits and locally obtained OK/nOK data to the centralized MCU instead of the underlying raw data to reduce timing and bandwidth challenges significantly.

While this approach contradicts the original intention to reduce the number of MCUs, it brings further benefits. The local MCU can enable standardized interfaces such as Controller Area Network-Flexible Data Rate (CAN-FD) or Ethernet 10BASE-T1S, and further introduce a uniform abstraction layer that helps enable pack multi-sourcing as well as cross-vehicle, cross-platform and cross-generation compatibility.

Let’s discuss some of the technologies within the BMS that can support these architectures and enable a more intelligent system.

At its most foundational level, the MCU has two primary roles within the BMS: connect to sensors to receive data and communicate that information back to the vehicle network. These two functions help bring functional safety and important diagnostic information, such as state-of-charge, to the BMS. Trends in MCU advancements today scale higher in both of those two main functions as more advanced sensing and computation and more advanced networking are required. Advanced MCUs, make it possible to send higher quality data from the batteries to the rest of the vehicle, helping provide a more accurate picture of what is happening within the car.

Look at advanced scenarios for MCU operation within the BMS. Computing power is increasing because of the need for complex algorithms to handle the intelligence required to maximize the usefulness of the battery. As the size of the battery increases, the number of individual cells that need measuring also increases. There are higher voltage levels and higher overall power stored within the battery. This all means that there are more signals coming in than ever before, requiring both an increase in MCU package size as well as the number of input/outputs as vehicle architectures transition from domain to zone control.

One approach to meet the requirements of these advanced algorithms and sensing needs is to increase the core computing performance. Traditional MCUs may have been able to operate in a BMS taking simple current and voltage measurements and temperature measurements with 100 MHz on a single core. Now there are multi-core devices running up to 1GHz that can compute and then act within the system. Designers could leverage digital signal processors and field-programmable gate arrays to build compute engines that are able to run at much higher speeds. TI’s Arm® Cortex®-based 32-bit MCUs portfolios include high-performance and power-efficient devices to help meet system needs.

The communication from the battery ECU to the rest of the car is also becoming more complex. Systems may need to perform diagnostics or implement dynamic changes such as predictive functions or toggling between task type depending on battery load. For example, if the car is running at a high speed, the battery will have a full load; thus it would be inefficient to perform tasks such as diagnostics or updating the cells. While the car is charging, however, there is more time and system bandwidth to perform these tasks and communicate back to the vehicle network, either wirelessly or wired over protocols like Ethernet, which provides much higher data rates than what a CAN or CAN-FD BUS could in the past. Depending on the level of modularization within the battery, there could even be communications required within the BMS itself.

The most important criteria for MCUs within the BMS is functional safety capability. Security is also becoming increasingly important, as networking levels continue to increase. MCUs need to support Automotive Safety Integrity Level (ASIL) D and have a built-in hardware security module to help meet the safety and security requirements of the system. Devices such as the AM263P4-Q1 MCU are multi-core and have much higher operating frequencies for computing with advanced peripherals for networking and the quality of the sensing and actuation IP. The MCU also needs to support open and standardized automotive software architectures such as the Automotive Open System Architecture (AUTOSAR) to help improve safety and reduce development time.