THIS ARTICLE IS SYNTHESIZED BY THE SEMICONDUCTOR INDUSTRY (ID: ICVIEWS).
Automotive manufacturers (OEMs) must shift their mindset and embrace open standards to make software-defined vehicles a reality.
Guests:
Suraj Gajendra, Vice President of Products & Solutions for Arm's Automotive Business Unit
Cadence汽车研发专家Chuck Alpert
Steve Spadoni, Area Controller and Power Distribution Application Manager at Infineon
Rebeca Delgado, CTO and Principal AI Engineer for Intel's automotive business
Renesas 汽车产 品线 高性能计算高级总监Cyril Clocher
Siemens EDA混合与虚拟系统副总裁David Fritz
Synopsys系统设计组高级总监Marc Serughetti
A very important aspect of software-defined vehicle architecture is security and confidentiality. How will this be combined with SDV?
Serughetti: Security and confidentiality are two key elements. Security is obvious. We're talking about people's lives. How do you bring safety into the car? How do you verify it, and do it in the process? How do you get the hardware to do this? The other aspect is confidentiality. When you think of SDV, it also means that the architecture will be massively integrated around the ECU and the chips used. This has a direct impact on security, because now that you have more software, you have more attack points against that software. You have more security concerns. These aspects are absolutely crucial in the development of SDV. I use the word "development" because that's also an important point to focus on in the context of SDV. You have the development part, which happens before the vehicle leaves the factory. But that's only part of the story. With the maintenance of vehicles, we are starting to see changes in the software side, which is a shift in mindset. How do you start separating software development from OEM-specific SOPs? These are all combined – security and confidentiality – and are very important parts of the SDV development and deployment process.
Spadoni: In the implementation of software-defined vehicles, the challenge is engraved on the software side and in the DNA of the companies trying to achieve this. These original equipment manufacturers (OEMs) are as much mechanical-centric as they are vehicle-centric. They think in terms of vehicle milestones, not in terms of software development. I've seen some of them start decoupling the two, so their software milestones are separate from the vehicle milestones. Their prototypes are starting to become more like mobile phones, such as iPhones, but this is only the beginning and is not universal. Everyone is at a different stage, which is interesting, but it also causes a lot of delays. Many projects have been postponed due to software development.
Delgado: At the recent SAE World Congress, one of the discussants said that as software complexity increases, so does the number of vehicle recalls. I totally agree that security and confidentiality are required in automotive use cases. We can sort a little bit between a mixed-critical environment and a very tightly knit deterministic workload. One element of software definition is ensuring that the right workloads are running in the right sockets. Then, the high-performance computing domain is needed to provide the necessary support for the user experience. In this centralized evolution, everyone is talking about software-defined. Everyone is talking about central computing, security, and confidentiality. The reality is that, given where we are today, there is a time variable between the level of centralisation and the level that the industry needs to achieve – perhaps slowly but surely, or painfully. However, as part of the software-defined requirements, some of the technologies that exist around virtualization must be enforced down to the hardware level to ensure partitioning and ensure that hybrid criticality is preserved. When you can trust how the action will happen, you can focus on efficiency, which is critical to this kind of system.
Alpert: One thing I haven't heard yet is the word "chiplet" that surprised me. SDV (software-defined vehicle) would not be a reality without chiplets. The reason for this is that it allows people to do plug-and-play. I want a low-end chiplet for low-end vehicles, or a high-end chiplet for high-end vehicles. This also allows different vendors to compete. But the point is, you have to be able to plug and play. You have to have common interfaces and standards like UCIe that will define that you can really do plug and play and everything will just work. I think of the whole concept of chiplets, the decomposition problem. Many years ago, we used another term – chips. And then we said, "Let's do the SoC." We can combine them all. "Now we're basically going in the other direction. This is thanks to advances in packaging and 3D technology, which allow you to now improve the interface between chiplets and go back to this on-the-fly decomposition model. The second thing to mention about software-defined architecture is that no one here wants to see automakers pay for a lot of copper wire. We'd rather they spend their money on silicon than copper. The zonal architecture allows you to save a lot of cabling. Also, copper is really heavy. The last area is security. This is an interesting question because we want to reduce costs, and for those who are at the ASIL-D level (i.e., the ISO 26262 standard that everyone is using), the easiest way to achieve it is redundancy. Not one chip, but two. But two chips or two cores are very expensive. It doubles the area. The key is how to use tools and technologies to achieve ASIL-D with less area, power consumption, and cost savings. In our functional safety solutions, we do aspire to provide a cheaper way for companies building silicon to do this.
What actions need to be taken to advance SDV in the short term?
Fritz: I mentioned the cultural mindset earlier. These companies still have business models that they need to generate revenue through model years, and the skill set required to deploy SDVs is very different from traditional electromechanical approaches. OEMs (original equipment manufacturers) need to get to the point quickly where they say, "We have two paths, and at some point they're going to merge." "Until then, the two paths were very different. The way they are organized, the operating procedures, etc., are all completely different. Otherwise, it wouldn't happen. If they move forward gradually, there will be more and more recalls as they try to outperform the capabilities of the hardware or software. So they need to take that approach, and we're seeing some companies thinking about that.
Delgado: The most pressing goal right now is to really work with the right ecosystem partners to provide solutions to OEMs so that they can grow in a diverse way. This is crucial. This has always been Intel's approach. We help other industries participate in an open way, providing open compute APIs, and then scalable to the chiplet products mentioned earlier. Intel was the first company to announce an open platform where the ecosystem could bring chiplets before all standards were defined. This collaboration is essential to truly deliver the efficiencies needed for the technology that already exists on the market.
Gajendra: Standards and collaboration, that's really key. In the short term, we need to agree on this. And then based on that, we need to build a higher level of infrastructure on all fronts.
Serughetti: I agree with the previous discussion about standards collaboration. Look at everyone in this roundtable, we've all collaborated. We compete, but we also cooperate to serve the industry. This collaboration needs to continue, and it needs to serve the market. I agree with David – it's all well and good, but no one will accept it if the change on the other side doesn't happen. These OEMs need to change. Eventually, change happens because if they don't, someone else will drive the change. Look at what's happening in China. This will force the entire industry to change, and it will be survival mode at that point. So yes, some of these companies have to change their way of thinking, and some of them have to change quickly.
Clocher: There are a lot of people in this group who are Renesas partners, and we can't build our products if we don't get the right intellectual property (IP) from Synopsys in a timely manner. At the same time, we're changing the way we develop hardcore silicon software. This is also part of the transformation of the company, which used to develop chips, developed SoCs (system-on-chips), and is now working on chiplets. For the industry as a whole, if we can all lease or buy these products for a large sum of money, then it will be a success. It can be SDV or other valuable technology. Through the software and hardware technology that we've developed together, OEMs have to open their hearts and minds and bring value to us when we go to a dealership and spend $20,000, $30,000, $40,000 on these cars. It's not our job. But we need to work together to deliver this technology that enables OEMs to do better, simply leverage the SDV platform of the future and translate it into new features and new user experiences.
Spadoni: From Infineon's point of view, the most pressing thing is the mindset mentioned. It's not just the OEM or Tier mindset, their organizational structure has to match it. This is not the case at the moment, and this must change in order for SDV to become a reality sooner. There are a lot of competitors around the world who are doing this, and everyone is taking notice.
Alpert: The mindset is a great point to make, and that happens. For companies that don't have this happening, they will cease to exist in 5 or 10 years. But it's also about speed. If the design takes a life cycle of 5 to 7 years, then how long does this take. The whole transformation and virtual platform had to happen, which meant that collaboration standards had to be in place. Companies that try to do everything on their own will not survive. They have to be able to collaborate, but then figure out how they can differentiate. Whoever can figure this out will win.
*Disclaimer: This article was created by the original author. The content of the article is his personal point of view, and our reprint is only for sharing and discussion, and does not mean that we agree or agree, if you have any objections, please contact the background.