Reliability and security top the list of concerns, but customization and lower cost could have significant impact on adoption rates for EVs.
Apple reportedly is developing a software-defined vehicle. But so are Renault, Hyundai, General Motors, and just about everyone else.
Some of the benefits of SDVs include increased comfort, convenience, safety, reliability, and remote software and firmware updates. Preventive and predictive maintenance, and remote diagnostics, can be done more conveniently over the air, while vehicle behavior will more closely resemble that of a computer. With these changes come many advantages. But they also add increased risks of safety-related software crashes, remote cyber threats, and significantly increased design complexity.
An SDV, as envisioned by the auto industry, includes onboard software to manage all the major operations within a vehicle, from driver interaction to infotainment systems and other instruments, ECUs, ADAS, sensor control, and communication. In addition, the software handles networking and communication within the vehicle, embedded operating systems, and over-the-air updates.
“Software-defined cars will go through an architectural transformation,” said Lars Ullrich, senior vice president of automotive for the Americas at Infineon Technologies. “Today we have a domain architecture, which includes infotainment, ADAS, vehicle motion, and body control. In the near future, it will migrate to a centralized ECU, which will control infotainment, ADAS, and vehicle motion. During this process, many MCUs will be deployed. Ultimately, SDVs will have a car computer managing everything from fuel efficiency to sensors, safety, security, infotainment, OTA, diagnostics, and more.”
It will take time for the automotive industry to evolve to the point where this vision can be realized, and market projections are all over the map. Straits Research puts the automotive software market at $58 billion by 2030 with a CAGR of 14.8%. Precedence Research, meanwhile, predicts the market could hit $107 billion by that date, with a compound annual growth rate of 17.4%. And because software needs chips and hardware to run on, including ECUs, sensors, power electronics, and other electronic components, McKinsey & Co. predicts the revenue from combined software and hardware content could reach $469 billion by 2030.
To capitalize on the future SDV market, OEMs and technology companies are teaming up like never before. And due to those collaborations, cars may look increasingly like data centers on wheels.
“While not on the grand scale of large data centers, vehicles are getting more of that look and feel due to the heterogeneous systems being developed,” said Steven Woo, fellow and distinguished inventor at Rambus. “They’re all trying to talk to each other. The software-defined aspect is that you’ve got this hardware that’s moving you around, so it should be the case that you can customize it to the look and feel you want. You see this with profiles in things like streaming media services and the like. And why shouldn’t it be that way? From a software-defined perspective, it should be the case that based on the need and the time of day — and almost the mood you’re in or whatever you need at that moment — you should be able to customize what the vehicle interior looks like, the type of music you’re playing, the type of video you’re getting, even the types of feeds and things that are brought to your attention. It will be similar to how homepages get customized almost automatically in some ways.”
Others agree. Renault Group noted that software-defined vehicles are opening up new prospects, and will enable savings in R&D and generate new revenue streams, especially from new connected services. Renault expects its first entirely software-defined vehicle, which is being developed with Google, Qualcomm, and other partners, will be available in 2026 under the Renault brand.
Qualcomm is working with Renault to co-develop high-performance computing platforms based on the Snapdragon Digital Chassis for the Centralized Electronic Architecture, which includes an SoC, low-level software, as well as in-car services and applications, Renault said. The work with Google includes an Android-based platform for the SDV, along with cloud software to enable an SDV digital twin.
Reliability improvements
Predictive maintenance to reduce failures, and in-car services to enhance the driving experience, are among the top goals, and Renault is not alone here. GM is developing its Ultifi platform, which integrates the cloud, an in-vehicle operating system based on Red Hat’s Linux OS, and a vehicle hardware network that includes hardware modules and wiring.
“Today, the market is driven by EVs,” said Marc Serughetti, senior director for embedded software solutions and software at Synopsys. “We know it’s driven by ADAS toward autonomous driving. We know it’s driven by connectivity, shared mobility and things like this. The challenge for the OEM, given this is what the consumers want, is how to start delivering a product that enables all those capabilities. In the past, the OEM said, ‘Here’s a new function, let me throw in a new piece of hardware that addresses this function.’ But with these new trends, you can’t act like this. It doesn’t work anymore. So they can’t say, ‘I need this functionality, let me throw in a new electronic control unit that’s going to have this function.’ It cannot work because those functions do not work independently. They are connected and interdependent with each other. The other piece is what consumers want. They know their mobile phone. They get updates, and upgrades. That’s what they want in their car. The OEMs are trying to determine the best way to provide this to the customer.”
Making this all work is easier said than done, however. “The way to achieve this is by having a lot of that functionality addressed in software,” Serughetti said. “There’s also an implication for the hardware. It starts with the mentality of thinking about software first, and how that impacts the product and delivery.”
In the hardware, Serughetti points to three levels of implications. “First, you cannot have the same architecture that you had before. You cannot have an architecture where all those ECUs are distributed all over and each has its function. You need a change in the electrical/electronics architecture of the car, which speaks to central compute, zonal gateways, domain controllers and the like being discussed today. There’s an entire evolution on that side that’s happening. And that’s to support the software.”
The second piece that comes into picture from the semiconductor side is what type of chip is needed. “You’re going to need chips that are very powerful for AI support,” he said. “And third is the software, because now there are all of those computing elements and you want to leverage that computing power. In the zonal architecture, for example, you may have a different zone controller, and a calculation needs to be done. Why can’t the compute power provided by one of those zone architectures be used? If I don’t get enough out of that, why can’t I use another part of the compute power in the car? The software-driven approach is impacting the hardware and software of electronics together, and that has implications. You can go in detail in each of those areas. You could say, from a software perspective, what does that mean in terms of operating system? Here, OEMs are starting to recognize they need to have their own operating system — not just a real time operating system, but rather the complete infrastructure. The software-driven car is changing the way people are looking at the architecture. They are looking at what type of semiconductors and SoCs are needed to support that, and the software that runs on top of it.”
GM’s Ultifi platform, which will launch this year, supports future software-defined vehicles by providing customers with new technologies and features, said Gary Cygan, director of SDV product management at GM. That platform also serves as a foundation for third-party developers.
Meanwhile, Hyundai Motor Group has teamed up with Sonatus, developer of the Sonatus Digital Dynamic Software-Defined Vehicle Platform, to develop the central communication unit (CCU) controller. The CCU will be used across Hyundai and Kia models as part of Hyundai’s planned transition to SDVs. Yu Fang, CTO of Sonatus, said computing, storage, and networking are converging, and that software-defined vehicles have become small data centers running many ECUs. Many vehicles contain more than 100 million lines of code. The cost of supporting such software updates can be significant. Taking a proactive approach, the Sonatus Digital Dynamics platform can configure itself dynamically by harnessing vehicle data, then respond by adding features and remedying problems without requiring software updates.
Risks of software dependency
An operating system is not just for desktops, mobile devices, or networks anymore. Windows, Linux, Blackberry QNX, Green Hills Software, iOS, and Android are now used in various zones in vehicles. As SDVs play a larger role, the key questions will be how safe are software-defined vehicles, what are the failover requirements, and how secure are these systems.
There are many considerations and challenges to be addressed in designing SDVs. They include system architecture, security, and safety. OEMs also must wrangle with in-vehicle networking, power, thermal, storage, memory, bandwidth requirements, and, most important, how to prevent failure.
Fig. 1: OEMs needs to develop SDV life cycle management for SDV. Source: BlackBerry QNX
As the shift to SDVs occurs, OEMs will need to develop SDV lifecycle management. As shown in figure 1, starting with development, the software will go through prototyping, road testing, production, and model refinement. With OTA updates, some problems can be fixed remotely. While it looks simple, the process can be complex, and mistakes can cause injuries. Therefore, it is critical to have a fail-safe operation.
One concept is to use hypervisors, such as those developed by BlackBerry QNX and Green Hills Software. Software can be compartmentalized, and critical software can be isolated. If something goes wrong in one area, whether it is caused by a software failure or a ransomware attack, the fundamental software continues running in real-time and keeps the vehicle operating in a safe mode.
Alongside of this, SoCs will continue to evolve, as well. “More and more functions will be performed by software and chips within the vehicle,” said Robert Schweiger, group director, automotive solutions marketing at Cadence. “A GPU is not always the most efficient processor for each and every function. Some of these high-performance GPUs consume a lot of power, generate heat, and may even require liquid cooling. Thermal management is important in automotive system design, but also can be very expensive. There is a trend that lower-cost, low-power chips will emerge. Not only will they reduce the overall system temperature and increase reliability, but the range of the EV will be improved.”
The automotive community is taking safety and security very seriously. Standards addressing these concerns include UN R155, ISO/SAE 21434, ISO 26262, and the Scalable Open Architecture for Embedded Edge (SOAFEE). Both UN R155 and ISO/SAE 21434 address cybersecurity issues. Starting next year, sales of 2024 and future model vehicles will require they meet all the cybersecurity criteria as stated in the specifications.
“Cars are becoming connected cars, and connected cars will evolve into autonomous cars,” said Maarten Bron, managing director at Riscure. “As much as cars need to be safe, they also are required to be secure. From a technological point of view, one could argue that the basic unit of security in a car is the ECU. How easy or hard is it for an attacker to compromise the security of an ECU?”
The answer to that question may depend on where the ECUs are made and by whom. In modern vehicles, there are upward of 100 ECUs, some from different manufacturers with different supply chains.
“Standards and regulations like ISO 21434 and UN R155 are aimed at the pre-conditions required for a vehicle to be secure,” Bron said. “This goes beyond individual components and instead focuses on the entire component lifecycle, including the design process, supply chain, production process, parts decommissioning, and even company culture. The end result is a secure ECU, and Riscure helps red teams to determine whether these are compliant with applicable security standards.”
The United Nations Economic Commission for Europe (UNECE) pointed out that, due to digitalization, today’s cars contain up to 150 ECUs and 100 million lines of code. By 2030, that could reach 300 million lines of code. To increase security, UNECE’s World Forum for Harmonization of Vehicle Regulations established four distinct disciplines:
Together with SAE International, (formerly known as the Society of Automotive Engineers) and the International Organization for Standardization (ISO), UN R155 and ISO/SAE 21434 were established. UN R155 is a regulation with specific directives, while ISO/SAE 21434 is a standard which established an engineering baseline for developers.
The ISO 26262 automotive safety standard has been around for many years. Today, many companies are helping OEMs get certified to ensure those safety standards are met.
“Due to a larger attack footprint and more functionality in software in SDV design, functional safety is critical,” said Frank Schirrmeister, vice president of solutions and business development at Arteris IP. “Getting everything right to design increasingly complex automotive chips can be challenging. If one thing goes wrong, it will compromise functional safety. For example, in an SoC, processor architectures may include multiple cores to support fail-safe modes. In such SoCs, redundant processor blocks need to connect to other MCUs and memory blocks. The connections between these blocks need to be error-free and reliable. Using resilient technology for the network-on-chip (NoC) interconnect IP, users can achieve ISO 26262 certification to increase reliability and safety.”
The SOAFEE standard is relatively new. In 2021, Arm launched the Scalable Open Architecture for Embedded Edge, or SOAFEE, special interest group across the automotive supply chain. That includes silicon vendors, software providers, system integrators, cloud service providers, and OEMs. That group now has more than 50 members.
SOAFEE is an open architecture defined by automakers, semiconductor suppliers, open source and independent software vendors, and cloud technology leaders. The goal is to deliver a cloud-native architecture enhanced for mixed-criticality automotive applications.
“As the automotive industry moves toward SDVs, the industry needs to overcome challenges presented by a software-centric future,” observed Robert Day, director of automotive partnerships for the Automotive Line of Business at Arm. “Developments for new automotive applications need to be fast, seamless, and functionally safe. SOAFEE, which builds on the success of Project Cassini and SystemReady from Arm, will enable a standards-based cloud-native experience at the edge, helping the automotive industry to move forward.”
Ensuring reliability
To increase the security and safety, the auto industry will need to rely on modeling and simulation to ensure the software and hardware designs of vehicles are bug-free and reliable. This is more pronounced in chip design. Million lines of codes need to be tested before chip fabrication. To correct a mistake can be very expensive. Chip designers are facing constant struggle of how much tests are needed versus how to shorten the time to fabrication.
“Simulation/modeling enables fast SDV development of software and hardware architectures and their interactions,” said David Fritz, vice president of hybrid and virtual systems at Siemens Digital Industries Software. “But there is an even more compelling use case of digital twins for SDVs that few have considered. Imagine there is a golden version of a complex digital twin like a car and all its ECUs. Now imagine every engineer has a copy of that digital twin used to develop, debug, and test software.”
If a change is made to the golden digital twin, by either the hardware team or another software team, then cloud-native software such as SOAFEE automatically pushes the updates to all the development digital twins just as OTA updates will happen in the physical car. “You then not only have a flexible SDV architecture, but also a software-defined development environment for developing and validating the SDV for a very large software team. All of this is enabled by digital twin technology.”
Conclusion
It is hard enough to imagine a modern vehicle run by more than 100 million lines of code, let alone 300 million. The challenge will be to develop safe, secure and reliable software programs.
Still, nearly all OEMs are at least exploring SDVs because of the market potential. Technology companies and OEMs are teaming up everywhere to develop future software-intensive vehicles. OEMs will need to treat automotive development as if it is a super computer. Standard compliance, modeling and simulation, safety and security considerations, implementation of new sensors, the innovation of ECUs and ADAS, and the changes in the automotive supply chain together will add much more complexity, but they also will provide much more flexibility.
“If we’re spending significant time in these autonomous vehicles, it’s an opportunity to have yet another screen,” said Rambus’ Woo. “It used to be three screens in your life. Now there’s the fourth screen, and maybe it becomes an opportunity for yet another screen. Even today, you can do things like move your services between a phone and a tablet, and seamlessly continue watching a movie. You’d expect that same kind of thing to happen for a car. If I’m a passenger, and I’m watching a movie, and I get to the really good part and we get home, the first thing I want to do is finish what I’ve been watching. In some ways, the industry is already laying some of that groundwork. On the flip side, it’s also true that there will be greater use cases that we haven’t even thought about yet, because it’s a new kind of vehicle.”
—Ann Mutschler contributed to this report.
 |
 |
 |
 |
 |
 |
 |
 |
 |
Leave a Reply