Challenges of Fitting More Software into Less Hardware
Today’s software defined vehicles need increasing ‘compute power’ and, to get smarter software, it has to grow.
Without it the industry wouldn’t be able to move more rapidly from dumb mechanical vehicles to much smarter ones with electronic controls. Manish Menon, global program manager, Frost and Sullivan explains that the electric and electronic architecture in modern vehicles is becoming a power surplus architecture. It is needed to enable vehicles to cater for on-demand features and functions. He elaborates: “Since these on-demand features and functions are installed post-purchase, via over-the-air updates, OEMs need to have additional computation power in the vehicle to meet the requirements of on-demand features and functions.”
He reveals that back in 2017 and 2018 the idea of domain controllers arose, which entails segregating the vehicle into multiple function-specific domains: “This was first used in the Audi A8 with the zentrales Fahrerassistenzsteuergerät (zFAS) system. When the system went into traffic jam pilot mode, the zFAS controller would control all vehicle operations by controlling ECU for cameras, radar, ADAS, and sending out data to the steering, powertrain, and braking system.”
Domain control architectures
Since 2020, he says some automakers are now segregating their E/E architecture. By 2025 he thinks that all automakers will deploy domain control architectures, or partial zonal architecture, where domain controller zones are created within the vehicle architecture. Zonal architecture will be defined by automakers themselves but the zones would typically be the front, rear, left and right sides of the vehicle. There could also be a centralized zone as a fifth option.
He adds: “Mercedes and BMW are moving towards partial zonal architecture with the aim of achieving full zonal someday. VW is migrating to a domain controller architecture and based on their needs might migrate to zonal architecture in future. The need to change the E/E architecture came in 2017. Up until 2000 and in the 1990s, the OEMs would add an ECU for a particular function.”
Centralized domain control units
David Mitchell, managing director of Futurice UK says vehicles nowadays often incorporate centralized domain control units. They are responsible for managing a vehicle’s various systems and components. In essence vehicles are becoming software-enabled with regard to their features and functions. This can permit the user experience to be customized and enhanced.
He explains: “In other words, the transition to EVs represents a significant move from mechanical to electrical control. EVs rely heavily on software and power electronics for power management, regenerative braking, and distribution.”
Danny Shapiro, vice-president of automotive at Nvidia adds that any redesign to have a centralized computer will inevitably replace numerous fixed-function devices and this can make it much easier to update the software used to enable them to function. Most discrete components in the past were only capable of performing a fixed function in the past. By having a centralized computer it’s now possible to continuously improve, for example, a car – just like people do with their smartphones.
“By being programmable, the systems can take advantage of the latest technology developments as the process moves from research to production,” he says before adding: “With a central computer in the car, we can take advantage of AI to enhance the safety of the vehicle, and to improve the overall user experience inside the vehicle.”
Decoupling hardware and software
Menon says this is leading to a decoupling of the hardware from the software. Previously, to add a particular function to a vehicle, there was a need to add an ECU. This meant that software in effect coupled with the hardware, so to add software for a particular function required adding ECU hardware. Automakers are now standardizing hardware across all their models and brands to allow them to become software-defined to the extent that the software becomes a differentiator. This is brought into the vehicle partly via in-built and/or OTA updates.
A large number of ECUs creates complexity in vehicle design and development. Shapiro reveals that cars nowadays have been 100 and 200 discrete ECUs. Not only is this adding complexity but also cost. It’s not cheap. With centralization of the computing costs can fall as vehicle design and development can be simplified.
This can also lead to improved power and weight savings in, for example, EVs. Subsequently, it’s possible to lower power consumption in EVs and that translates into greater operational range. Shapiro adds that the development and maintenance of the software is also easier with a centralized system.
Menon adds: “We have moved to a consolidation phase. You have limited space in the vehicle. You cannot complicate the wiring in the vehicle, and that’s why OEMs decided to migrate to a domain or zonal architecture to support cloud computing, and OEMs’ requirement to shift their business models, and to ease the E-E architecture complexity.”
Migration benefits
The benefits of migrating to centralized computing systems in vehicles include the ability to process data more quickly at more efficiently than distributed systems permit, says Mitchell. This creates enhanced responsiveness and functionality. He explains why this is important: “This is crucial for features that require real-time data processing, such as ADAS and autonomous driving. In addition, centralized computing reduces the potential entry points for cyberattacks, making it easier to implement robust cyber-security measures.”
Shapiro offers his own example: “From a development perspective, many different systems can be connected via software, such as connecting the front-facing camera to the wipers. The system can be programmed to recognize raindrops and trigger the windshield wipers or have a GPS-based system that knows when your car is in the garage and does not activate the automatic locks. From a safety perspective, occupant monitoring cameras could detect a distracted or drowsy driver and provide appropriate alerts or corrective action when needed.”
He warns that a supercomputer is being put into each vehicle. For this reason, there is a need to think about safety and cyber-security. They are critical and so there is a need to use data encryption, authentication and virtualization to ensure that data is secure as well as to ensure that nobody outside the vehicle can take unauthorized control of it. Safe and secure operation of any software-defined vehicle – whether connected, partially or fully autonomous is essential.
Safety and non-safety critical
With zonal architectures, there will be a division between safety critical and non-safety critical functions within the same zone. Many of them will be computed centrally, although it’s also possible for functions to be computed in particular zones. For them there will need to be a failsafe. Safety critical applications include having a centralized control and management of things such as brakes, suspension, cameras and LiDARs. The failsafe will enable the vehicle to adapt to ensure that when the central compute fails, the vehicle will be able to stop safely. To do this the non-safety critical functions would need to be stopped because they don’t have an impact on vehicle safety.
He concludes by emphasizing that hardware is still in the vehicle, but some of the software is not in the hardware. “More hardware and less software will occur in the vehicle to allow automakers to charge the consumer,” he says while predicting a consumer backlash. That’s because consumers will often be reluctant to pay for anything that’s hidden behind a paywall without having seen any tangible benefits. The hardware is already available in the vehicle but the frustration arises from not having access to the software to be able to use it. It’s often locked behind the paywall.
Consumers demand tangible benefits
Consumers need to be able to see the tangible benefits first whenever it comes to feature and function on-demand. He thinks that automakers also need to standardize their hardware across their groups. Yet, this in itself comes with a problem. Menon suggests this could lead to consumers feeling they’re getting a sub-standard product. So there needs to be a differentiating factor.
He explains: “Bentley would have to offer, for example, more features than an Audi. OEMs will never be able to judge the computing power, so they will have to have an architecture that is surplus in nature. This adds cost. As the vehicles are becoming software-defined, it needs to be cyber-secure.”
From a vehicle design and development perspective, it’s about reducing the number of ECUs to simplify the process, to make them more efficient. This includes future-proofing the vehicles by making them more software-defined. In that sense there will be more software and less hardware.
