Unit vectors

Peter Donaldson reports on the latest development trends in engine control units, and the factors driving them.

While the entire powertrain of an EV is much simpler than that of a typical modern car with an internal combustion engine, the number and sophistication of the electronic control units (ECUs) distributed around road-going EVs in particular continues to grow as more functions within the powertrain, chassis systems, driver aids and automation require computer control. Also, more of them have to be certified to safety standards, particularly ISO 26262, which governs electrical and electronic safety in road vehicles.

ECUs in modern EVs have tended to follow similar patterns of functional division to their internal combustion counterparts, although those concerned with the powertrain naturally have to reflect the fundamentally different nature of systems based on batteries, inverters and electric motor/generator units. One expert acknowledges that many EV manufacturers use high-level architectures with a great deal of commonality between vehicles, but with different requirements for functions and features in the particular application, and unique selling points for product differentiation given high priority.

ECUs are generally categorised according to the type of systems they control rather than by vehicle class. For example, lighting ECUs in various classes of vehicle share more characteristics with each other than they do with the supervisory vehicle control unit (VCU) in the same vehicle. Lighting ECUs are in all vehicle classes, while VCUs tend to be specific to EVs and hybrids.

Another expert points out that VCUs interpret the driver’s intentions (whether the driver is a human being or an autonomous system) and puts those intentions into action. It therefore has a high functional safety requirement.

ECUs in the vehicle conversion and some other specialist markets differ in the way they carry out their tasks from those used in production EVs. For example, a VCU for a road-going EV would not have the programming it needs to execute a burnout for a drag racer, or to execute transmission shift strategies and control torque delivery to avoid wheelspin in the highest performance EV applications.

Performance-oriented applications also need different strategies to deliver the maximum energy available, and that requires special attention to the data from the battery management system (another ECU in its own right) to optimise temperature and voltage.

Using an ECU from a production vehicle in a conversion can also be problematic, as the EV it came from is likely to impose limitations that make it unsuitable for its new application – assuming it can be made to work at all.

Most EVs use the Controller Area Network (CAN) comms standard for their onboard electronics. It is wellproven, flexible and reliable, but it can also prevent the ECU from working in conversions if in its original application the VCU is designed to allow the motor to work after validating that all of the original controllers are communicating with each other. One way around that is to program the VCU to provide full torque management while retaining the ability to communicate over various CAN networks.

Growing demands

The demands on EV ECUs have been growing rapidly in recent years, and are revealing two clear trends. The first is the need to meet the ISO 26262 functional safety standard, the second is to future-proof architectures by enabling ‘by-wire’ control and actuation. The latter adds networked smart, single-function actuators and sensors needed for tight closed-loop control that are coordinated by serial comms from a domain controller such as a VCU.

Functional safety is the most potent catalyst of change, with the relatively new ISO 26262 standard driving the software and hardware maturity of components in vehicles that are designed for public roads.

That means control units need dual- or multi-core processors, safety monitoring and redundancy built into them. They must also go through validation to prove that every line of code and every item of hardware has had a safety case built for it, and that a failure modes and effects analysis has been completed and that it complies with the standard.

In most EV applications, the demand for greater power from battery technology takes a very high priority, whether the emphasis in the application is on speed and acceleration or on energy efficiency. Improving range is particularly important to eliminate range anxiety for drivers new to EVs, while in the highest performance applications the ability to deliver the highest possible voltage for consistent performance is critical. Managing this power across multiple inverters and motors requires advanced strategies implemented in the VCU to ensure the vehicle remains competitive.

EV ECUs are also expected to control more parameters than ever, largely because there are more sensors than ever on the latest vehicles. This is particularly so with the integration of advanced driver assistance systems (ADAS) and autonomy of various levels, and with the use of fine-grained subcontrol loops to maximise inverter efficiency.

Everything has become more modular over the past decade or so. Each module needs more inputs and outputs, because the equipment they control – Lidars, cameras and ultrasonics, for example – is getting smarter and needs more sensors.

There is also therefore a much higher volume of data to be handled, and at the same time there is growing demand for smaller electronic hardware.

According to one specialist, the trend is splitting into two branches, with smart actuators and sensors being given more limited responsibility while domain controllers coordinate larger areas of the vehicle. This hierarchical approach enables greater system flexibility and a simpler development, maintenance and upgrade path.

The need to control more parameters is particularly evident in the highperformance and vehicle conversion markets, says another specialist supplier in this area, and is addressed through software and expanded comms channels. The supplier’s software provides engineers who need to program and calibrate ECUs with what it describes as complete control over multiple parameters, including torque curves, traction and launch control, variable regeneration strategies, map switching and power limiting.

The company’s VCUs are built to communicate with all the motors, inverters/controllers, DC-DC converters, high-voltage contactors, pre-charge resistors and battery management systems it has validated. That enables engineers in the conversion market to combine different EV powertrain systems and get them to work together to meet their requirements. The VCUs also use OEM safety models to ease validation.

Measurement and control

While precision might be thought of as a good thing in its own right, implying a mantra of ‘more is better’, greater precision of measurement and control is only really necessary in a few specific areas in the EV ECU space.

One of these is where it leads to lower energy losses and therefore greater efficiency in primary traction motor drives, where more precise measurement of current across ranges encompassing mA to kA helps to optimise battery pack performance. Others include drive-by-wire systems and those with higher levels of autonomy.

The position of a torque pedal, for example, has to be measured with great precision and accuracy. It also has to be measured using twintrack potentiometers for a degree of redundancy and inherent self-checking capability by comparing the two output signals.

The increasing speed of electric motors is reflected in higher baud rates over CAN comms systems. This is where greater precision is more relevant, an EV specialist notes, arguing that things that are spinning quickly need to be checked quickly. Autonomous vehicles also need to communicate among more subsystems and process their data more quickly. Memory requirements are also increasing, and that is driving the automotive industry to turn to Ethernet and fibre optics in applications for which CAN is not fast enough.

While vehicle manufacturers’ own VCUs for road-going EV powertrains offer a great deal of precision, our high-performance and conversions specialist believes it is insufficient for these applications, and has proved to be a limiting factor in their growth.

Control philosophy

A different philosophy applies to EVs from that which applies to IC engines in control terms. An engine ECU directly controls all the parameters that need controlling through direct connections to sensors and actuators, whereas a VCU for an EV acts as a central control and coordination hub for many subsystems’ ECUs using high-level commands.

In the simplest EV control architectures, the ‘throttle’ pedal potentiometer sends its signal directly to the inverter. In most cases, however, the signal goes into a supervisory VCU that does the torque mapping to tune response to driver inputs, along with the torque arbitration, which is part of traction control.

The VCU then sends torque and speed commands over the CAN bus to the inverter controlling the motor. The motor also has sensors including an encoder on the shaft that feeds its rotational position back to the inverter for closed-loop control.

Because EVs these days are so dependent on CAN comms, many of their ECUs have three or more CAN bus channels, with some using the CANFD standard for greater bandwidth. In ECUs associated with ADAS functions, comms with even higher bandwidth such as Automotive Ethernet are common.

The powertrain in a pure EV is much simpler than in an IC-engined vehicle (or a hybrid), with roughly half the number of components, and the control architecture reflects that. Such relative simplicity lowers the barriers to entry for new players in the vehicle market, with the legacy of a large code base for controlling IC engines providing only a minimal advantage to established manufacturers.

However, considerable sophistication is needed in battery management systems to control charging and discharging, to minimise wear on the battery and to ensure the most efficient use of the available energy. The aim here is to reduce range anxiety and charging time for EV drivers.

As a result, the total power budget for vehicle electronics is much more tightly specified for EV ECUs. For example, the cabin HVAC is often part of a wider thermal management system that also serves the battery pack, onboard charger, inverters and motors.

One of the main challenges with ECU development for EVs is that the shift to electrification is coinciding with a push towards automation, which brings other factors into play to increase performance requirements. One of these is system cost, which is driven by the battery’s status as the most expensive item in the car. That means that without government subsidies, EVs remain at a disadvantage.

One method of driving down overall cost is to use cheaper endpoints such as sensors, and fewer but more capable ECUs.

Also, the effort to drive down overall power consumption is leading to the consolidation of control functionality into fewer nodes.

Domain or zonal?

Wiring is another factor. One specialist points out that, depending on the vehicle, there can be two or three miles of cabling in cars, which is both heavy and expensive.

That is because most vehicles use the domain control concept, in which all the controllers for related systems form their own networks. For example, the connectors for the doors and the seats form one domain, while the braking system’s components form another.

That looks set to change, however, with the adoption of zonal architectures. Here, all the subordinate controllers for different systems in one physical area of the car – the front right corner, for example – feed into a single ECU, which in turn is connected to a central controller such as the VCU by one long cable.

That can reduce cable requirements to hundreds of metres per vehicle – as Tesla claims to have done – with the potential to shorten them further. In consequence, however, zonal controllers have to deal with systems with very strict real-time deterministic performance needs, such as braking systems, along with less critical systems such as windscreen wipers and seat controls.

The adoption of Ethernet, 1 Gbyte at first and then possibly 10 Gbyte, will also reduce cost.

The other factor driving ECU performance requirements is ADAS, notably features such as detection of lane departure and loss of driver attention. This is also increasing the need for on-chip memory, as systems are programmed to track events before and during an accident.

While ECUs for modern IC engines need very high processing power for measuring parameters and rapid control of effectors such as ignition coils and fuel injectors to manage combustion efficiently, EV ECUs have equally complex but very different problems to solve. Inverters, for example, have to measure and harness high currents, voltages and data-rate signals while ensuring the efficiency and durability of motors and power electronics, one specialist emphasises.

Management of the battery pack is also a major challenge, because it is a core differentiator for EV manufacturers, affecting vehicle range and battery durability. The specialist describes the task as multi-dimensional optimisation across temperature, current, voltage and state of charge, requiring precise and accurate measurements over six orders of magnitude (0.001 to 1000 A). That drives very sophisticated specialised ECUs and battery management systems.

Multi-core processors

The electronic and physical architectures of ECUs and the EVs in which they are used are also evolving, taking advantage of the benefits of Moore’s Law and shifting away from relays and fuses to direct transistor control of their systems, and protection with advanced diagnostics. There is a natural progression to faster and more reliable processors and other hardware to handle increased demands.

In terms of computing hardware, the latest architectures are dominated by 32-bit, floating point, multi-core processors, while physical architectures are also influenced by improvements in power electronics. Modern power supplies operate in switched modes more often than in linear modes, and feature sophisticated low-current sleep modes with multiple ‘wake’ options activated by CAN messages or discrete signal inputs.

The automotive industry is in the early stages of transitioning from single-core, single-thread computing architectures to parallel multi-core, multi-thread. Diagnostics, functional safety and cyber security for example are all being considered for implementation on separate processor cores and in separate software processes.

One EV architecture specialist says that for safety-critical functions in the powertrain, braking and steering systems for example, their approach is to develop an ECU containing two processor cores. One runs the main application software while the other checks constantly that it is working as expected, and assumes control if it detects a problem.

Vehicle network processors for embedded applications are now available with multiple cores and memory types, network acceleration, security engines and large numbers of interfaces for different comms standards including CAN buses, FlexRay, USB and serial ports on a single piece of silicon. These devices can handle multiple vehicle systems with different levels of criticality.

System-on-chip (SoC) vehicle network processors are becoming increasingly sophisticated. One high-end example has three ARM Cortex-M7 processor cores running in lockstep, with an option for two pairs of Cortex-A35 processors operating as a lockstep cluster. In lockstep computing, two or more processors run the same set of operations at the same time in parallel, enabling comparison between them to detect errors and, with three or more processors, automatic error correction.

There is a functional block on the chip dedicated to catching and correcting errors. It groups together a fault correction and control unit, logic built-in self-test, memory built-in self-test, phase-locked loop for clock synchronisation, safe direct memory access and a debug and trace unit.

There are also sections dedicated to memory, serial and parallel network interfaces, security, timing and analogue-to-digital conversion and network acceleration for dedicated automotive and Ethernet networks.

Flexible hardware

ECUs for EV applications are also taking advantage of reconfigurable hardware in the form of field programmable gate array (FPGA) processors included in SoC chips on the same piece of silicon. FPGAs allow engineers to apply new logic circuit designs as updates to existing chips throughout the service life of the vehicle, although changes to safety-critical systems have to be certified.

According to one FPGA specialist, this technology is being used in areas subject to rapid innovation. These include driver and passenger monitoring for safety, and for gesture control of infotainment systems, as well as ADAS and self-driving technology in all cars and for battery and motor control in EVs.

The benefits of FPGAs in an EV powertrain applications stem from their flexibility. An SoC that includes an FPGA allows engineers to put timecritical functions either in software or in the FPGA’s programmable logic, the specialist says, dedicating hardware logic gates to the tasks.

Implementing high-speed inverter control modal loops in this way enables nanosecond-level precision in switching frequencies to make the most of highfrequency silicon carbide inverters, for example.

In the same way, the system can also dedicate hardware and software to sub-control-loop compensation to remove unwanted harmonics that cause spikes of energy-wasting electromagnetic interference, squeezing more range out of the battery.

FPGA hardware can be tuned down to general-purpose input/output level and individual clock cycles in real time, the specialist says. That means tailored control schemes can be applied not just to different models of battery, inverter and motor, but to individual batteries, inverters and motors, adjusting the control scheme to allow for production tolerances and in-service wear and tear.

This is based on models of expected behaviour compared with measured behaviour in the real world.

Hypervisors rule

The key to using such advanced hardware to run multiple applications of different criticalities while ensuring that they don’t interfere with one another, and that they remain safe from cyber threats, is to control exactly which resources are put at their disposal and which (if any) comms paths with the outside world can reach them.

One category of software that does that is the hypervisor, which runs right on top of the hardware, with only the basic input/output system between it and the silicon. It can be thought of as a virtual motherboard that gives the system architect access to hardware resources including memory space, processor cores/time and interfaces.

That enables them to allocate the resources to the tasks the car has to carry out, from braking and motor control to HVAC and infotainment, secure in the knowledge that the behaviour of the safety-critical systems will be deterministic. That means for example that every time the driver (human or robotic) hits the brake there will always be enough CPU cycles to deliver the required braking performance, regardless of what any other system is doing.

An SoC might run Linux for example on some of the cores, with other tasks running real-time operating systems with guaranteed determinism. The hypervisor ensures that those tasks don’t share the same memory so that the infotainment system, say, cannot put anything into the space allocated to the braking system.

Cooling

Improvements in power electronics are also reducing the heat generated in power transistors and increasing the number and size of the electrical loads that can be driven by an ECU, which consequently are getting smaller and more feature-dense.

However, higher density electronics can also put more heat into less volume, while battery packs, power modules, inverters, converters, touch screens, and high-power boards for the automatic drive systems are all powerdense devices.

This is creating a need for greater cooling capacity and new thermal management concepts based on a shift from air to liquid cooling. Liquid cold plates for example have greater heat transfer, make less noise and are more reliable than die-cast heat sinks and/ or heatsink-and-fan combinations, and could therefore replace them.

In IC-engined vehicles, engine and transmission control modules are relatively low power, using simple electronics and convection cooling from the module body to dissipate heat from the electronics and provide thermal management for the module.

However, the cooling needs of the complex electronics that run vehicle control systems with increasing levels of autonomy are much greater. This functionality relies on a large number of sensors that feed their inputs into high-performance computer modules, which rapidly evaluate the data and provide feedback to the vehicle control systems that adjust driving parameters.

In Level 4 and 5 autonomous systems, data volume and processing rate increases exponentially, at the level of 5 Tbytes per hour of driving. Handling this volume of data requires the equivalent of a server in every vehicle.

This is causing a major shift in electronics packaging and the associated thermal management technology applied to vehicle control modules, the cooling expert says, and is compounded by the transfer of functionality and capability into other vehicle electronic systems. Battery control modules, for example, will increase in functionality, so the thermal management techniques applied to them will also become more complex. In the design of data processing modules for vehicles with higher levels of autonomy, thermal management solutions are becoming similar to the types of technologies applied to typical high-power servers. These include heat pipe assemblies to enhance conduction to the module’s outer casing, vapour chamber assemblies to spread the heat from high-power components and, in the highest power applications, liquid cooling for the electronics.

Pumped liquid cooling in such applications is a dedicated loop that is often coupled to the vehicle’s climate control system. These solutions are integrated into the module enclosure, which can then form a sealed package to protect the internals from the harsh automotive operating environment.

With multiple ECUs in the vehicle, thought has to be given to the most reliable and robust means of cooling them all. One option our cooling expert mentioned is to divide the main liquid circuit into sections to avoid the risk of a leak in one affecting the entire system, while an alternative might simply be to provide a secondary liquid circuit dedicated to less critical electronics.

Depending on their location in the vehicle, different ECUs might be exposed to different temperature ranges and might therefore need different types of coolant, particularly if they are exposed to the risk of freezing.

Cyber security

With increasingly connected vehicles, cyber security is a major concern. Several well-publicised hacks have accessed the vehicle network via the onboard diagnostics port, exploiting the fact that CAN is an old standard with no inherent security.

One expert suggests that the CAN bus will be around for decades to come, so it will have to be ‘buried’ to make it inaccessible. However, the shift to Ethernet for example vastly improves options for security.

The expert also stresses the importance of separating and isolating functions so that the software running the powertrain and brakes, for example, should never share memory with an app that is running the infotainment. Any communication between them is strictly controlled, which hypervisor systems for example can achieve.

Vehicles connected to the internet, another expert says, need to limit the number of connection points – preferably to just one – and provide them with levels of protection comparable to firewalls. Meanwhile, internal networks need additional means of confirming the trustworthiness of inter-ECU comms, using cryptographically signed or fully encrypted messaging for torque requests, for example.

Some developers keep their VCUs off the air, ensuring that they can only be connected to a laptop using a CAN-to-USB cable.

Future directions

In the longer term, security by design, through the development and implementation of standards such as SAE J3061 and ISO/SAE 21434, will be increasingly important.

More broadly, the definition and development of unified standards for system architectures will be important in future ECU development, as legislation and increasingly comprehensive requirements from organisations such as Euro NCAP push for greater driver safety. Increasing the market appeal of EVs will also require further efforts to address range anxiety.

In addition to the drive to integrate more functions into larger VCUs, to reduce costs, there will be a need for still greater processing power, more capable functional safety architectures, more memory and higher comms bandwidth.

These will be coupled with fewer discrete inputs and outputs, and greater use of smart sensors and actuators.

There is also likely to be competition between domain and zonal control architectures. The latter will possibly dovetail with new power conversion architectures based on more local power conversion through inverters and DC-DC converters with innovative connections to the battery packs.

Acknowledgements

The author would like to thank Lawson Mollica at AEM Power, Jerome E Toth, at Boyd Corporation, Ian Ferguson at Lynx Software Technologies, Gordan Jurasek at PI Innovo, Richie Frost at Sprint Power, Mathias Ptacek at TTTech Auto and Wayne Lyons at Xilinx for their help with researching this article.