Automakers today are undergoing the biggest upheaval in their industry and market history. Electrification, automation and connectivity are all happening at the same time. In turn, these three unstoppable trends are fundamentally altering the way car OEMs must design, develop, test, validate, manufacture, maintain, and update their cars for their entire life cycle. The culprit that has triggered the revolution is software.
The value of a new car will no longer reside in just how it looks at the time of its rollout. Value, rather, will hinge on how the vehicle evolves over time. Buyers of new cars will more and more expect additional features, functions, apps and services to pop up magically in their cars, via software updates.
Individual hardware components still matter. But software that runs on top of them has become crucial in the new generation of automobiles.
Welcome to the brave, confusing new world of software-defined vehicles. For this disruptive change, credit goes where it’s due: Elon Musk.
Rudy Burger, managing partner and founder of Woodside Capital, told the AutoSens audience, “[Elon] Musk is clearly an entrepreneur…he is prepared to take a big bold risk to keep Tesla out in front, in terms of innovation.” Such software-driven innovations are exactly what Musk brought to the automotive industry. Tesla can update and upgrade its vehicles via over-the-air software.
Software-defined vehicles
In designing a software-defined vehicle, the wrong approach is to start selecting hardware components. However, many car OEMs and tier ones are used to doing this, first by pondering which specific hardware — camera or radar or lidar – must be deployed in a new ADAS or highly automated vehicle. But this approach would only serve to render their next-generation vehicles more hardware-centric rather than software-defined.
In his keynote, Raj Vazirani, director of engineering at ZF Group, warned that carmakers should start laying out “vehicle requirements and architecture” first. Next would come system requirements, followed by functional and software requirements and architecture, he explained. Such a vehicle- and system-level strategy can enable carmakers to spawn several different models that share system, functional and software architecture, effectively reusing software.
The idea of software-defined vehicles becomes particularly important if carmakers think about scaling up their SAE Level 2 cars to Level 4 vehicles.
Woodside Capital’s Burger noted, 50 percent of new vehicles shipping today are already equipped with ADAS functions using camera-based sensors. Even though fully autonomous vehicles “keep getting pushed to the right,” as Burger said, it is a matter of time for current-generation ADAS vehicles to progress by absorbing more automated features.
The game for carmakers, then, becomes how to handle such progression via software updates. The last job any car OEMs wants is rearchitecting a whole vehicle, throwing more hardware at new models and rewriting the entire software architecture.
Centralized vs. De-centralized architecture
Benefits of software-defined vehicles to carmakers are clear. And yet, actually designing an architecture that meets all the OEMs’ requirements is not easy.
ZF Group’s Vazirani discussed extensively the challenges facing carmakers –either with a decentralized system (which many companies are using) and a centralized system in the future.
Problems well known in decentralized systems include constraints related to the number of sensors that can be configured, limitations on fusion capabilities due to the needed computational power, and issues with integration and time synchronization.
Current-generation centralized architecture isn’t a panacea, either. Certainly, going from L1 to L4 poses scalability headaches. Perhaps even thornier for carmakers who chose to centralize is, as Vazirani asked, “Can your architecture scale down from L4 to L2?”
Other problems that need solving include the management of domain controllers and their functional split, whether they can reuse the optical path, and how they can reduce software complexity that stems from integrating various platforms. Last and maybe most, let’s not forget that the cost of such a centralized system will be too much for entry and mid-category cars.
Vazirani is not saying these dilemmas are insurmountable. In a centralized architecture, he suggests that OEMs focus on using scalable ECU architecture and standardize a complete platform from system functions down to software level. To combat a centralized system’s high cost, he proposes smart camera sensors as the ADAS domain ECU.
A question on everyone’s mind
A $64 billion question for everyone racing to develop software-defined vehicles came from a participant at the AutoSens: Who will succeed in combining all the components in a scalable, maintainable, and reusable ADAS, AV solution?
Benni May, co-founder of Obsurver, noted that success won’t come from a single player. “I don’t think there will be one company that can say that I have everything, I can give you all the sensors, all the software, and validation, everything together.” It must come from a combination of companies who understand collaboration is important, he explained.
One example could be Mobileye/Intel, already test-driving AVs in Munich. Mobileye is using not only their own EyeQ SoC solution but also radar and lidars developed by others. “That’s one approach,” using a traditional collaborative model, acknowledged May.
On the other hand, Alexander Braun, professor of Physics at the University of Applied Sciences, Dusseldorf, told the audience that he sees a world split in two. While Tesla pursues its aggressive vertical model, the rest of the players are sidelined, or scrambling to cobble things together. He explained that Tesla already has a million cars running on the roads — navigating real-world conditions every day. “Tesla is using L2 ADAS vehicles while running L4 algorithms in the background… seeing the differences and discovering the heavy tail of unknown scenarios,” Braun pointed out.
Tesla’s inherently software-driven approach might be giving the company unfair advantages available to nobody else, suspects Braun.
However, Tesla’s software upgrading strategies, such as the recent Full Self-Driving (FSD) beta rollout, could invite scrutiny from regulators. The question is whether Tesla owners begin to abuse the FSD beta by putting other road users in risk. But that’s grist for another story..
