Panel Discussion: Role of Semiconductors in Shaping the Software Defined Vehicle Era - MATLAB & Simulink
Video Player is loading.
Current Time 0:00
Duration 1:10:28
Loaded: 0.23%
Stream Type LIVE
Remaining Time 1:10:28
 
1x
  • Chapters
  • descriptions off, selected
  • en (Main), selected
    Video length is 1:10:28

    Panel Discussion: Role of Semiconductors in Shaping the Software Defined Vehicle Era

    Moderator: Rashmi Rao, MathWorks

    The automotive industry is experiencing a transformation with the emergence of software-defined vehicles (SDVs), where software capabilities increasingly define vehicle functionality and user experience. Semiconductors enable the seamless integration of computing, communication, and control systems in modern vehicles. This panel discussion brings together industry leaders from the semiconductor sector, original equipment manufacturers (OEMs), and Tier-1 integrators to explore the technical challenges and opportunities in advancing a more software-centric automotive future. The conversation focuses on how technologies can drive innovation in SDVs, support computation power, facilitate adherence to safety and security, enhance connectivity and ultimately, and redefine customer experience in the automotive landscape.

    Published: 23 Dec 2024

    Good afternoon, everyone. So I've already been warned by the MathWorks colleagues that I'm between you and lunch, but I promise you, this will be an interesting session before we take the first break, right? So we have talked a lot about software right from the beginning, and can we have the slides on the screen, please?

    Yeah, and while we were doing some research to set the base for this panel discussion, my colleagues and I found this very interesting report. So it's interesting on many levels. If you look at the estimated lines of code, it's about 100 million lines of code that the future of automotive will see, and interestingly, it's more than a Boeing 787, apparently. It's also more than Facebook code, so that's a lot of code that we are going to be talking about.

    I also want to point you out to the name of the report, and the report says that we are moving away from ICE. How many of you in the audience remember what ICE is? Internal Combustion Engine. And this KPMG report actually says that the ICE of the future will be the Internal Computing Engine. I personally like that.

    I'm an ICE person, so I like to see ICE, even if it means something different, right? So with this quick introduction, we want to discuss what this means in terms of semiconductors for engineers, like you and I. How will application software development change? How will virtualization change? What may be some of the future trends that we will see as this software defined vehicle sort of becomes a reality?

    So I have a very interesting panel, and I'm going to request them to come on stage one by one. Now, the panel has also been chosen very carefully. So we have an OEM perspective. We have a semiconductor perspective, and we, of course, have a tier 1 or an integrator perspective.

    So please, put your hands together for Karthik. Karthik is a semiconductor industry professional with over 22 years of experience, and he is currently the Senior Director of Engineering for the HPC group in Renesas, India. He leads the systems and application engineering efforts focused on ADAS/IVI/Cockpit products all across the RCAR SoCs.

    So Karthik, welcome on stage. Yeah, looking forward to a lot of interesting discussions with you, both from the Renaissance perspective and from the experience that you have in the semiconductor industry. So thank you, Karthik, for joining us.

    Next, we have Ramanathan Annamalai, and within MathWorks, he is well known as Ramzan. So I'm going to refer to him as Ramzan, today. He has over 24 years of experience, expertise in automotive electronics domain. He also leads the newer areas, especially under IoT and the digital transformation area. He is primarily responsible for defining the future solutions of automotive electronic systems and, of course, caters to customers, like global OEMs and tier 1's, and helps them define their digital transformation journey. Ramzan, welcome.

    [APPLAUSE]

    Next on the panel, we have someone representing a company that's probably bringing in most of the IPs that we are seeing in semiconductors today. So Sukhianju Srinivasan, Director of Go-To-Market at Arm, has 24 years of industry experience. With a BE from Madras University, she also has an MBA from IIM Bangalore. Suki is a strong advocate in the automotive technology industry, fluent in six languages, although the panel here will be in English, and a devoted parent of two. Sukhi, welcome.

    [MUSIC PLAYING]

    Next on the panel is a very important voice, the OEM voice, and it's Pune and of course, it's Tata Motors. So Rajiv Kumar, General Manager with 23 years of industrial experience in system delivery in the area of electric and hybrid vehicle powertrain, his specialties include embedded system development, power electronics, battery management system, functional safety, and of course, the software defined vehicle. Currently, he is leading an embedded and power electronics system development group for the development of an electrical vehicle powertrain as part of the advanced engineering group in Tata Motors. Rajiv, a very warm welcome from MathWorks.

    [MUSIC PLAYING]

    So I request you to be seated. OK, so we have, basically, divided this panel discussion into four rounds, right? And I'm not going to reveal what the rounds are, keeping it a little bit suspenseful or keeping your curiosity here. But we thought a good way to start this discussion is to look at what really is the current state of SDV.

    Of course, Kishore Jim have done a great job of putting that perspective together in the morning talks. But I also want to turn to you, Rajiv, and ask you, what are some of those factors that are driving the adoption of newer architectures, especially SOC based architectures? Why is there a necessity, basically, to move into this kind of architecture? So if you could share your inputs from an OEM perspective on this transformation and get us started on this discussion.

    Thanks. Thanks, Rashmi. I think good one to start with, because why SoC? So yeah, let's put it from three key factors or, like, three key drivers perspective, like customer, then the industry, the overall industry, and the OEM perspective. So let's start from customer.

    Like today's car buyers, most of them, we call it Gen Z, right, young ones? And they are now exhibiting a traditional shift when they go to buy or when they decide to buy a vehicle, a car. Their preference is more from connectivity, safety compared to the traditional one, where the mileage, the fuel efficiency, and the cost were the deciding factor, while choosing when to to decide to buy a vehicle. And they also, like for all the advanced features, like in-vehicle entertainment, in-vehicle connected system, then electrification, autonomous vehicle, ADAS.

    These factors also plays an important role, and all of these have very software and electronics intensive, right? And also, today's customer is also influenced by the similar industries, like smartphone, or online shopping, or trends, like AI sustainability, health. So since now, as I said, these are already-- the vehicle has, like Rashmi has been started, that a vehicle already has many controllers, millions of lines of codes, very complex wiring harness, and even putting these new features, which require very frequent updates. Like, it has already reached to the saturation, right?

    So now, this requires two critical change, one on the vehicle E&D architecture, and other is the software architecture with the fact that, now, the software and hardware needs to be decoupled. If we see the present, like the traditional, how the software is being developed, where we have for any features or any bug fixing, what we do, we build the software. We integrate, build, test, release, then flash, and it's all even with a small-- you need to build the entire code, right? So this is a time taking process. Why it is required? Because this architecture is the signal-based, where software is very much coupled with the hardware.

    So now, what we require, we need to decouple this, right? So when we decouple, even a small introduction, any new feature can be easily deployed and very swiftly with the automated test cases and all. But this requires, again, two major change. One is the HPC, and the other is the journal architecture.

    So present one is distributed where every function is having an issue, like a controller. So what we need to do, now that safety is centralized, journal based architecture, and then HPC based centralized journal architecture, where all the sensors and actuators, which are very much embedded with the controller, they will be in the zones, like they were the controllers, and then they will connect to the HPC through the middleware. That's what is the critical for the HDB architecture, and this change will require swift deployment and any new feature introduction. So I think this is what is required, and this needs to be scalable modular, so yeah.

    Absolutely, absolutely. No, thank you. Thanks for explaining the need from an OEM perspective, more features, scalable architecture, decoupling of hardware and software, which sort of takes me to the next question. So Karthik, I'm going to turn to you here.

    So we have spoken at a very theoretical level about moving from a microcontroller based to a microprocessor based or more SOC architecture. Could you take us through some of the actuals, especially in the context of an RCAR? What really does that mean for engineers?

    Hello. Sure, Rashmi. So if you think about an SOC, an SOC has a far greater offering as compared to a microcontroller. You can think about it in two perspectives. Firstly, in terms of compute, it has a lot of specialized hardware accelerators for image processing, for GPU, for AI accelerators, and so on, and so forth. And it also brings in a lot of peripheral connectivity options to drive in a lot of data into the system and out of the system, so a lot of cameras, radars, lidars, the displays, lots more displays, and traditional automotive peripherals, as well, can be brought into the mix in a single integrated package.

    Now, with this integrated package on an SOC, what you could do is we talked about, Rajiv talked about a lot of ECUs and a lot lot more challenges, and I think it offers the ability to integrate many of the functionality into one single ECU, one single automotive ECU, and to be able to manage it very efficiently in terms of being able to deploy and during the entire product lifecycle to make maintenance updates and so on. It allows you that opportunity. And, secondly, with this integration, it also brings in design efficiency, power efficiency, because these devices are designed for the specific purpose, and we could bring in a lot of those efficiencies into the thing. And plus, during the entire product life cycle, you also need to have headroom to maybe deploy some feature need that comes in at a later time without adding an additional ECU, without having the car being driven back into the dealership.

    So the SOC based approach is really the way to go in terms of building the ECUs of the future, and last, but not the least, compared to an MCU, the SoCs are also running high level operating systems, like Linux, Android, or QNX, or similar other offerings. And these type of development environments allow for rapid prototyping, and it also allows for very quick deployment and time to market. So that's how I would distinguish it.

    Wonderful. Thank you. Thank you, Karthik, for sort of breaking that down for us. So the next question, Sukhi, I'm going to turn to you. So we are seeing a lot of these evolving tech trends, but we're also, in a way, seeing that the value chain is transforming, right? So how do you view, basically, this opportunity for semiconductor companies? And we know, with the evolution of technology, how is the value chain and the ecosystem in a way emerging?

    Thank you, Rashmi. Before I start, I would like to thank MathWorks for inviting me here. It's a great environment to interact with all of you here.

    So just from automotive industry's going a big shift, from morning from Sunil to Jim Tung to Kishore. They set up the stage, saying what's happening. So there's ask for more autonomy, more advanced user experiences, which Rajiv also spoke about.

    Electrification is happening in a larger scale. And as you also mentioned, hundreds of lines of codes are being in a car and increased AI. So we just had the session about AI. And a lot of mixed criticality requirement is also required in the vehicles now.

    Now, because of these different requirements which are emerging, the business models are also changing. Rather than the traditional IP provider to silicon provider to tier 1 to system integrator to OEM, that supply chain is now disrupted. In fact, everybody are talking to each other. They are trying to see if-- OEMs are trying to see if they include vertical integration, and software providers are directly talking to IP providers and also to the OEMs. So a lot of business models are emerging, very interesting era to be there.

    Now, from a semiconductor perspective in this situation, one is, of course, these challenges from because of the requirements, its performance, scalable performance, safety, security, and also power efficiency. These are the requirements which the market asks. But actual challenges are not these, if you ask me. From a software-defined vehicle perspective, the challenges are more from mixed multiple software requirements. So if you can share the next slide, please. Yeah.

    So it's about multiple software. Extremely in auto world, it's not a single software. It's a lot of legacy code out there. Multiple hardwares use different types of software verification, very rigid hardware as well. And a lot of lack of this cloud-to-car tools and infrastructure.

    Thankfully, MathWorks is bridging those gaps. And requirements for more the OTA kind of features. So now the industry requires standardization and from semiconductors and from software as well flexible hardware and flexible software is required.

    And virtualization is a must. It cannot be-- it's not an optional thing anymore. It's a must. And of course, the ISA parity, which we will talk about it a little more in detail later, how it helps, these are the things which semiconductor companies have to look into to make this a reality. Yeah.

    Thank you, Sukhi. That was very insightful, flexible hardware. I love that term.

    So Ramanathan we'll come to you. So we are speaking here about a lot of pieces that need to come together. And I think the main essence of Kishore's talk was integration. So I'm picking up on that thread with you.

    As an integrator, I'm sure you have seen a lot of these challenges. So what are some of those challenges? And how do you, as a tier 1 integrator, how do you basically overcome them?

    So good afternoon, everyone. First of all, thanks to you for inviting me to the panel and MathWorks for organizing such a wonderful event, where you bring in like-minded people to exchange ideas.

    So this SDV is being there in the industry for a couple of years. A lot of discussions are happening. Whenever we talk about that one example, which fascinates me, is about not-- though it's not from the technology domain. It might be from the toy industry. So just many of you would have lived or played with this toy and would have seen with your kids playing on that.

    What I'm talking about is LEGO bricks. So if you see that in their journey of what they are currently at this point of time, in the second generation of the LEGO bricks, where they are reinventing themselves, what they did is that they tried to do two main things, which resonates very similar to what the automotive industry currently are envisaging at.

    One, they brought a systematic approach to the play area. Before that, there was no systematic toy which is available in the market, and this was one of them. And the second thing is that they try to standardize how the LEGO bricks are joined together. So it's like holding a glue, which, if I have to draw parallels, it is how you have in the SDV paradigm, the service-oriented architecture, how it is going to standardize on that.

    So this, with the thought process that this toy should last for the lifetime, the value of the toy is not just bought it, played, and left. It's there for the lifetime. And that's what is happening in the industry at this moment of time.

    So when we talk about that, the integrations, as we see on the keynote address for Jim and Kishore, a lot of emphasis on the integration happening. Why? Because, in this juncture, we are trying to integrate multiple domains to function together, either as a part of one single chipset or multiple chipsets. So that is important to identify how the architectures are going to evolve. That's point number one.

    Point number two is that how they are going to interface. The interface is-- another critical aspect is the applications, which is residing on top of it, will eventually will undergo a lot of change. Like Rajeev was mentioning, that the features on demand is going to come, and it is have to be installed.

    Like I said, the toy, the LEGO brick, which I purchased maybe 10, 15 years back, I still can hold good to the current toy, which I am going to buy for my kid or someone so like that. So they have to hold together and execute, so the interoperability and as well as the way they are communicating.

    And the second point is that we have seen the industry, like Jim was mentioning, that there are lot of shorter lead time to development and others. So it means that all these things are going to happen parallelly. So when we talk about parallelly, there is every instance, some-- one component or other is not going to be available. So it is how you are going to fill that gap for the validating your successful integration and how a critical component are simulated.

    So what we see currently in the industry is that more and more systemic approach, I would say, that a system of systems, which is being currently happening in the automotive industry, which is integrated and thereby promoting a lot of focus on the system engineering aspects. That's point number one.

    Point number two is that how you can simulate virtualization. When I talk about virtualization, it's not about simple virtualization because it, again, brings a challenge of how the real-time performances are being met because we are not talking about real-time hardware. It's predominantly either going to run on a PC or a cloud environment. So how the real-time behavior is validated.

    And the third is that all of them are developed in various time zones, various distributed development environment. So it is very essential to have the CA, CD, or CD pipeline within an organization to standardize and as well as have the team work together. And also the first-- the last one is that try to shift more from a software to a systemic approach is what I could see at this point of time.

    Thank you, Ramanathan. So really, the systems approach or systems of systems approach with regard to integration. So that's got us warmed up a little bit to what we are seeing in the industry for the current state of, if you may, a software-defined vehicle.

    So let's now delve a little bit deeper. And most of you here being MathWorks users will be interested in, hey, how does that affect the development of application software? So in round 2, let's take a look at some of those aspects. And Rajeev, I'm, again, going to turn to you to set the tone here.

    So we've understood why it must change. But from a very user perspective, what are some of those on-demand features that you foresee? I mean, and also if you can help us to understand the customer's expectations, especially keeping in context of the Indian situation, what are some of those features that the so-called updatable software-defined feature vehicle should cater to?

    Yeah. So yeah, so I can, again, bucket these into three or four different buckets. So the first one is some of the default features, which will come from the variant selection. We call it personalized and whenever somebody is going to buy a car. Now it can be enabled through software.

    Second one is the continuous updates. Continuous updates, due to regulation, due to bug fixes, like the maintenance updates, or due to-- and these are mostly OEM posts, which are not monetized or revenue. These are post [INAUDIBLE] some of the predictive safety features, like in case of battery, some of the updates needs to be required. So that comes under the continuous updates.

    Next one is the most important one is the monetization, how these can be used to generate the revenue. So they are like-- maybe some of-- mostly for the fleet operators. Depending on the specific duty cycle, some calibration needs to be done.

    Suppose some of the features , like suppose cruise control, when I bought a car, I didn't-- because my driving, the cycle-- my drive cycle doesn't require. But when I am going for highway driving, I can go and subscribe for cruise control. But that is a subscription based.

    Similarly, like predictive control prognostics, some of the safety alerts, these can be on demand or revenue generation. There could be some features which could be data based, like you pay insurance premium as per your behavior, as per how much kilometers you are driving. Or the data can be even given to the third party to analyze the driving behavior. So these are the most of the features, which, yeah.

    Thank you, Rajeev. That's very helpful. I particularly like the insurance-linked one. Maybe it makes us better drivers. We'll see.

    So moving on, Ramanathan, I'm going to turn to you. How will the software architecture actually change to accommodate these so-called features on demand? If you could, give us your thoughts on that.

    So just, again, when I was talking about-- we are talking about a systems, which is coming into picture. Second thing is that the hardware, like the copanelists, they have talked about a lot of changes happening on that.

    So what in terms of the feature on demand, one critical component, which lies between the application and the hardware, is the essential element, which are now currently being developed from an software perspective. So if you see here, from a zonal point of view, it typically will follow a legacy architecture is what we have seen.

    The main changes from a feature on demand is happening at the central compute or the high-performance compute. In this, as you could see here, the layer which holds together or interacts or the glues the application to the hardware is important. The service, it's called as the vehicle OS. Many of the OEMs are working towards and a lot of consortiums is also working towards standardizing this one.

    So now, if we talk about a minute on, this component is not a purely a middleware, per se. It's going to a combination of operating systems or the hypervisors, which brings in the virtualization and abstracts the hardware element and give it to the middleware.

    Now, this middleware from a legacy system is also undergoing a lot of change in a way to adapt themselves for the service-oriented architecture. While we do this, what's happening is that, for example, our traditional diagnostics is also getting evolved to the SOVD, the service-oriented vehicle diagnostics. And this gets coupled with the middleware.

    So you try to orient your services, orient your diagnostics. And then what's happening is that it's very important to abstract the service-- the vehicle information. The reason is that we are going to integrate multiple systems. So there have to be some common entity which supplies the information, which is consumed by the applications for changing or taking controls actions on that.

    So this, what we have seen is that there is one layer called vehicle services, which are coming up. This, for example, a typical brake information or engine speed, the vehicle speed information, which is common across various domains, are being serviced by this particular layer. And it is getting consumed by the applications.

    Now, it comes to the application. Typically, it migrates from the legacy to adapt themselves for a service-oriented architecture. So a lot of changes go from a model-based domain And. as well as on the legacy software, migrating into that. A lot of reorientations happens on this.

    The essential element, what industry is trying to put together at the whole, as a common, is about standardizing this particular architecture for interfacing. We started this conference with a quote that from Mr. Ratan Tata that if you want to walk faster, walk alone. And if you want to walk longer, then you walk together. So that's what we could see in the industry that both, like Sukhi was mentioning, the OEM, tier 1, the technology service providers. Everyone is coming together to address this particular challenge. So that's why.

    Thank you. Thank you Ramanathan. So moving on maybe to the next question in this segment, Karthik, MathWorks, and Renesas have been collaborating in a way to ease the friction, if you may, for customers to develop and deploy these softwares. So can you throw some light, both on the initiatives of Renesas with MathWorks and otherwise on how you're helping the industry, if you may, to develop and deploy this application software? Yeah.

    As we-- as I mentioned previously, in terms of the SOCs offer you a lot of compute. They're very capable. They're very powerful. But that also brings in a complexity in terms of designing it and to get it right. And we have to make it easy for our customers to be able to integrate all the features into one automotive VCU.

    So firstly, I think, as a semiconductor company, we are investing heavily into providing the software elements, which will be optimized for functionality, for power, and for the general API compatibility, and so on.

    We recently announced the RoX platform, which is the R-Car Open-access SDV platform, where we are partnering together with a lot of different companies, from hypervisors to many of the OS providers to the virtualization companies and also more tools. And we are going to do more.

    And specifically with respect to MathWorks, I think the tooling, the tooling that MathWorks offers, essentially helps to control this whole complexity. We have seen a lot of those in the beginning. There are also some demos there which demonstrate a very, very good what do you call putting together, working together of all of the elements.

    So these tools, we are continuing to work together to essentially integrate all of Renesas offerings to be compatible with what MathWorks provides. Thereby, we create common value for our customers. And I think the whole idea is to help customers to get full potential of the hardware without really dealing with the complexities of the hardware by itself, so some kind of abstraction. So that's the direction that we are going to go to.

    Wonderful, wonderful. Karthik, I love that philosophy of abstracting the complexities of hardware and working together to help basically application softwares develop.

    So with this, we'll go to the-- oh, sorry. One more question coming from Sukhi. Sukhi, you did speak about some of the collaborations in the first question. But when we talk to Arm we think of SOAFEE as well. So we wanted to hear from you a little bit more about the SOAFEE consortium, how they are helping the industry, basically, to reduce the friction, improve collaboration, especially in the context of application software development. So Sukhi, over to you.

    Yeah, so as I mentioned, SDV-- to flourish SDV, we need industry collaboration. And it's not just not SOAFEE. It is we have SDV alliance. We have AVCC. We have IMEC, focusing on various specific parts of the standardization.

    So SOAFEE, being-- Arm has been a governing team and along with MathWorks being one of the voting members. So there are 140 industry companies participating in this. How SOAFEE helps is it basically looks at standardization from a cloud native development to the car.

    So that's the focus on SOAFEE. So if you look at the software stack, the full software stack, from firmware to OS to middleware to your application layer, so the orchestration and containerization is very important aspect for that for portability and from cloud to car technology.

    Now, what's in there? We have ISA parity instruction, set architecture parity between cloud and the car. The same architecture, underlying architecture, is Arm 9.x architecture running. So which is like, OK, the software, which is compiled functionally, working on cloud, will work on car as well.

    But that's not enough. Car has very different constraints which, in cloud development, people may not know, for instance, the timing sensitive stuff, the safety criticality, the mixed criticality. And these are the things SOAFEE is bringing in. So all the members of SOAFEE are working together to bring in some of the blueprints, reference implementation through which the developers can learn and see how this can be done effectively.

    Thank you, Sukhi. That's very helpful. So now we'll move to the third round.

    We spoke a little bit about current state. We spoke about application software development. Now let's get our panelists to talk a little bit about virtualization.

    Rajeev, I'll, again, start with you. And I think enough has been said about meeting cost and time deadlines, crunched vehicle programs, and so on. So we definitely understand virtualization is crucial.

    But how extensively can we front load? How much of that real-world testing and dependency on hardware can be reduced? And if you can, to this audience, set sort of a goal, as an Indian industry for OEMs, this is what I would like to see in terms of virtualization, what are your views from an OEM perspective? Yeah.

    Yeah. Virtualization, whether SDV or not SDV, like to start with the model-based development, which is already in practice, where Matlab Simulink, most of the model-based development happens through Matlab Simulink. So where you can check, verify your software early in the design phase.

    With reference to SDV, I think two important-- two other important aspects, one is the digital twin. I think the digital twin is like the virtual replica of your system. In this case, it's the vehicle.

    Where this will be-- digital twin, when we say it is twin of your system or vehicle, where the real-time data, like from sensors being fed into these models, and they will give you the predictive-- the analysis, which will give you a clue for the software updates.

    This is now, especially for electrification, the battery digital twins, even for ADAS, autonomous vehicles, where you can infuse the census data and can predict. So digital twins are becoming very pertinent, very critical aspect of the SDV. Other important aspect is the DevOps, like the CI/CD pipeline, where the continuous integration-- you have the integration build, which I spoke earlier, also.

    All these can be automated in the cloud. And any updates, either through bugfix or any new feature, can go through this CI/CD pipeline. And the software can be updates very quickly. So CI/CD pipeline, then AI-driven use cases, where scenario-based use cases can be modeled and infused into the AV, or autonomous, even for battery models to predict the battery health.

    And so in a nutshell, virtualization in this SDV era is going to play a very critical role. As Karthik was-- we were earlier speaking about even the virtualization of the SOC, where-- when we are setting up the CI/CD pipeline, even the hardware is not available, we can simulate. So this is very pertinent and very critical aspect in this SDV era.

    Thanks, Rajeev. I think that's really decoupling the hardware development from the software development in a way. Yeah, so to keep this thread going, Ramanathan, I will turn to you.

    Again, as an integrator, what are some of those challenges that you are seeing in virtualization, in terms of technology or in terms of skill or other areas? What's stopping us from getting the most efficiencies from virtualization?

    Before I answer, I'll take a moment. It's like when the standalone issues are there. When the applications models are developed, it's predominantly focused on the simulation. And that's what Jim was talking in his keynote address. The simulation is getting replaced with the virtualization, or a lot of focus is coming from a virtualizations.

    Wherein we bring in the aspect of the systems, so that's one thing which I like about his talk. It's really resonates to what's happening in the industry at this moment of time. If you see, for the SDV perspective, the simulations are happening at the unit level, system level, or the systems of systems level are changed.

    And what's happening is that all these components are developed parallelly. It's not happening in a sequential manner. It's happening in the parallel to address the lead time requirements, which is there. From this perspective, one, what we have seen in the current industry is that a lot of focus has been done to simulate the virtual ECU, which helps in validating one particular domain, one particular system.

    Now, the next set of focus is that when the systems are getting integrated, how you are going to simulate, predominantly the SOC simulations, how it is going to happen. Or when there is a talk, which I heard about, simulating the vehicle digital twin also, in the sense that wherein you can have the architecture, the EA architectures, which are being in research, can be simulated along with the core component.

    So why I'm saying this is that because there are three main challenges at this point of time. One, how you are going to validate your integration. Second thing is that the real time, how you are going to validate because all of them are not going to function on the target hardware. It's going to be on a simulated environment. So at this moment of time, how that real-time performance is getting monitored and validated.

    And second-- third thing is that which is very, very critical is that all the systems are integrated. And we have seen the growth in the complexity. And it is very essential to validate this complex integrated system to all the edge cases. And there we see a lot of enhancements or stress coming from utilizing the AI or a generative AI to come out with various scenarios or coming out with a synthetic data generation.

    And also one of the area of what we see is that on the test case because the test case test vector simulations is also going to matter a lot to validate the systems. To put-- summarize this, there are three main challenges how you are going to simulate the system and the SOC plus the vehicle. And then how you are going to build your robust pipeline. So that's what we are seeing in the industry at this moment of time.

    OK. Sure. Thanks, Ramanathan. That's very helpful. So Karthik, I want to move to you a little bit here and ask you, how does virtualization change when you move from a microcontroller world to a microprocessor world? If you can throw some light on that.

    So I think we've talked a lot about virtualization, and there is some questions about virtualizing the SOC and so on. Let me try to throw some light on this. So when you think from a semiconductor company point of view and you talk about virtualization, there are actually two aspects.

    The first aspect is virtualization of the development platform or virtualization of the SOC itself, which is what many of you were alluding towards. This is not something new, just to be clear. I mean, in terms of it's not something new.

    So semiconductor companies have used these virtual development platforms traditionally for a very long time. But these have stayed within the company up to the time when the chip is out. And then everybody moves into the hardware.

    But as, I think, over the last few years, a lot of technology advancement has happened, which effectively allows this virtualized development environments to live to the entire product life cycle. So even as a semiconductor company, we want to run simulations real time to essentially go fix a few, do a few tweaks, and so on but now we are seeing the desire even from the OEMs and the tier 1s to essentially use this virtualized development platform for the entire product life cycle, even taking it to the extent that you want to take it to the digital twin, where you're also simulating the SOC and so on.

    So that's the first aspect. The second aspect when you think about virtualization as a semiconductor company is the support for virtualization on the device when the actual software is running on the car. So you talk about things like hypervisor. You talk about things like all the peripherals having an ability to really be virtualized, the driver support, the tooling support, and so on and so forth. So we are working on that area as well.

    So we support many of the hypervisors. The silicon is designed with a virtualization in mind. And this also becomes very important because, as we talked about integrating a lot of functionality on one automotive ECU, it also becomes important because people want-- I mean, OEMs are thinking about architectures, where they are integrating all the functionality. But they are also separating out the blocks by virtualized-- by virtual machines or by containers or some of these things.

    So these are the two aspects of virtualization. But to answer your question, the scale of the problem is higher on a microprocessor as compared to a microcontroller. But I think, fundamentally, we are moving towards a very virtualized development environment in a very virtualized the associate software architecture as well.

    Yeah. Thanks, Karthik. I like the perspective of the hypervisor and the virtualization inside the SOC that you brought in. Thanks for that.

    Moving on, and before I go to Sukhi to ask her the question, Sukhi, when we were discussing for this panel discussion, I shared with you an example that MathWorks put together. Jim actually showed you a later version of this demo that we have built with AWS, which actually has the virtualized arm Graviton here.

    So Sukhi, now the question to you, again, coming from arm, we spoke about SOAFEE. I want to hear from you on how we can use the cloud more for virtualization.

    Absolutely.

    Yeah.

    So we did touch upon how the cloud native development to car in the SOAFEE discussion. And now, taking the example of AWS Graviton 4, the cloud has ARM cores, ARM architecture. And most of the vehicle, the SOC, more than 90% I can say have ARM architecture. Now, how can we leverage this to ARM architecture' availability in cloud as well as in the vehicle? So that's the concept behind it.

    So now the instruction set architecture, because it's the same Neoverse cores in the cloud or servers, and in the vehicle, it's automotive enhanced cores. But underlying architecture is the same. So from a software perspective, functionally verified, functionally built on cloud should ideally run as is on car now, we discussed about SOAFEE, how it brings the differences, how it's trying to bridge those gaps.

    Now, we are also having partnerships with several EDA companies, like Corellium, Cadence, and others. And what they do is they build virtual platforms on AWS, which helps the developers to run the software to get the cycle accurate mode. And why it is-- as Karthik said, it's not a new concept. It has been there for some time now.

    And why it is even more interesting now because, unlike the x86 servers earlier, now with AWS Graviton 4 having ARM architecture, it's much more faster, and it's much more easier. And why it is important for developers? It's using MathWorks Simulink tools.

    They can develop much more faster. And of course, the V cycle we discussed at length, I think, in the morning everybody. Mentioned about the V cycle. Now, as I mentioned, it's the same thing, which is being illustrated in this slide in terms of how the architecture parities bridge between the cloud to the final car platform.

    And of course, the SOAFEE blueprints and then the underlying helps for the developers to kick start rather than they do from scratch. And what we have seen by doing this, this left shift in the next slide, is o-- we save almost about two years of life cycle. Otherwise, without this virtualization concept, it was a serial development of software.

    Now you can already start as soon as the IP is available, not even wait for the entire SOC. So you can start the software development. Of course, the integration on the physical environment has to happen finally, but you can save a lot of time. And time is money.

    Wonderful. Thank you, Sukhi. So we are talking about front loading to the IP now, which is very interesting. So I'll skip this, I think, Sukhi. We spoke about it.

    So this is the last round. And I request my panelists to do a little bit of a rapid fire in one minute, your thoughts on what is the future state of SDV. And Rajeev, I've always started with you, so I'm going to end like this. OEM perspective, where do you see this going?

    Yeah, absolutely. So it will start with the organizational change. Organization needs to go through the change. Though mechanical, material science still will play an important role, but software and electronics is going to play a very critical role.

    So organizational change, not in engineering, all sourcing, purchase, quality, manufacturing, all need a paradigm shift. So that is foremost the most important part.

    Other is the ecosystem development, like the collaborations, which Sukhi has talked about, SOAFEE and all. Collaboration, starting from semicon, middleware, operating system, all these with open source, so that is-- at industries, we have to collaborate and work together.

    The next important aspect is the talent and infrastructure development. We need to nurture our talent, like safety, security, perspective, as well as the process model-based system engineering aspects. All these needs to be taken into consideration.

    But we need to keep in mind that this will be incremental. It will go through phases. We may say it's a soft SDV middle, then full-fledged, where we may have in between the journal-based centralized, where may have more than one HPCs, which finally go into where we have-- because you need to have the hardware also capable of having-- fulfilling the functionality for all [INAUDIBLE] and all. So yeah, this is what I can see.

    Yeah. Thanks, Rajeev. Over to you, Ramanathan. And while you're speaking about the future state, we also want to touch upon one important aspect, the functional safety. So if you can throw light on that aspect as well.

    Yeah. This is one very essential part because, when initially I was talking about we are trying to integrate multiple systems, typically in the vehicle, so you have a safety domain and the nonsafety domain, which is there. So when we are going-- then they are going to coexist.

    There is a lot of challenges comes from how you are going to preference, what is the arbitrations is going to be given for the safety system to function without any degradation to his functionality.

    So what we see in the industry is that, through our relationship and the research, what we are doing, there are different schools of thoughts, which are coming whether you have a software bifurcations, which are there, or hardware bifurcations, which is happening, going to happen. So how you are going to have, if I summarize that, the typically the safety is being envisaged to be there in one of the controllers. And then you have a nonsafety environment.

    And to ensure the functional safety, there is a thought process that the safety [INAUDIBLE] language could be used on the chip set to ensure the ASIL level, which is required for those functionalities. Now, when we move into the higher autonomy, this single controller is also not sufficient to take care of the redundancy, which is coming. And there we see a trend that there are multiple domain controllers or central computes for a safety domain could come into existence. That's one thing.

    And also, like the SOC, lot of changes are happening and becoming more powerful day by day. And when there is a chance that or what we see a lot of semiconductor industries, they are coming out with the chipsets, where the safety domain and nonsafety domain can coexist in the same controller. So typically, we are talking about having a software-based isolation for ensuring the functionalities on that.

    So the virtualization or the containers based approach, which is there. And here, one another thought is that, even though we can have a safety element, but it is important to have the freedom of interference and the freedom of operations, which is also coming on the associate. And for a safety, there is a possibility that a companion MCU, which specifically focuses on the redundancies and as well as failsafe operations or two integrated systems. That's what we are seeing at this moment of time.

    Sure. Thank you, Ramanathan. Those are great insights. Moving on, again, Karthik, moving to you, and when you speak about the future state, I think what we also want to touch upon is, now, our car is typically working with automated driving, with cockpit. You also said IVI. So what are some of those areas where you're working on to enable this sort of integration and this future state that we are speaking about?

    In terms of-- firstly, I think we are going to continue to build on the RoX platform because it is now starting to integrate a lot of aspects of the SDV, cloud native development, virtualized development environment. We talked about the hypervisor and so on and so forth. And then we're going to add more tools and more integration with all of our partners to make it a more interesting and compelling offering.

    The other aspect of it is, I mean, AI is now being pervasively used. And we had a talk, a wonderful talk, a little earlier. So we are also investing in terms of adding an AI workbench on top of the SDV to take advantage bring your own model, optimize it, and then just run it through a tool chain, and bring it over here. So that's going to be integrated to the SDV as well.

    But having said all of this, the demand for compute, for ADAS and cockpit, is just going up and up and up right. And you cannot scale by making larger SOCs because there are quite counter, opposite requirements about thermal and other things. So one of the things that our platform has recently done is we've launched the Gen 5 SOCs, which is effectively taking it towards a chiplet architecture, which allows performance scaling because everybody wants more performance but, at the same time bringing in some amount of power efficiency. So we're going to integrate a lot of those tools into the RoX platform.

    And then it also provides the isolation, which you were referencing about in terms of the mixed criticality system coexisting on a single space. So there's a lot of infrastructure being built in the SOCs to take care of those needs. And so yeah, this is what we are going to do in terms of making sure that we put the right tools into the product developers to take advantage of this SDV era, if I may call it that. Yeah.

    Thank you, Karthik. That's insightful. And now quickly moving on to Sukhi, Sukhi, you're where the IP comes from. So what do you have in store for us?

    As I said earlier, hardware has to be flexible.

    [LAUGHS]

    And Karthik just said more performance required, more ADAS more IVI more central compute. Now, how do we match all this? So that's where ARM has the various soft solutions for automotive.

    So most of them are automotive enhanced, which means they are ASIL compliant, B, D. So we have from MCU offerings M-Class, to real-time course, R-Class, to a little A-course, which can be for smaller ECUs, to the larger cockpits with ADAS and IVI. We do have a cluster of A-Class course with a compute cluster. And for vision applications, we have GPU and ISPs as well.

    So it's a wide range of things. And what we are seeing is in the industry, from a time-to-market perspective, people are struggling taking the IPs and integrating and coming up with solutions. So what we are doing to help the industry in terms from time-to-market perspective, we are trying to see how we can make compute subsystems, which is very tuned to automotive applications.

    And these are the compute subsystems with the cluster of our own IPs, which will cater to various applications of configurations. And that is what we are seeing as a step forward. And this is what we expect in 2025 to come up. And this is, again, from faster to market and total cost of ownership reduction for the OEMs from that perspective.

    Sure, yeah. Thank you, Sukhi. Thank you for that sneak peek.

    Well, I was going to say you can go out and see the demo booths, and there's a range of things that we spoke about in terms of workflows and targets. But I think Karthik kind of said that before me, but nevertheless.

    Do use the lunch break to visit our demo booths. Like I said, there are a lot of these workflows on how MathWork tools can integrate with these targets is on display here. For more customer stories, this is a QR code that we left that actually showcases how customers use our tools, which you may find interesting.

    And very quickly, moving on, we've not taken any questions since morning. But this is your chance. So if we can have a question or two, and then we can all go and enjoy lunch, that would be great. Yes, yes. If someone can get him a mic there.

    So when we are decoupling hardware and software, typically we are thinking about processor point of view. But the beauty of microcontroller, the internal peripherals, like DMA, or peripheral reflex system, so when you too much decouple, how we can get the advantage of these hardware peripherals?

    Karthik, do you want to take that? Yeah, yeah.

    What I mean is the persons at the top, they don't how exactly a peripheral works, or they don't know-- might not know they can use these kind of peripheral. Or directly I can trigger if the software, I have to make a task, I have to make multiple function calls to invoke something. But I can simply do from a trigger. So we are missing that advantage if you decouple, right?

    So I heard most of the question, but I'll try to respond. So firstly, like I mentioned, when Renesas provides the SDK and we provide the platform enablers, we make sure that we take care of using the hardware efficiently and making sure that we provide you standardized APIs that will not have to deal with the underlying DMAs or how things work in terms of separation.

    Of course, the source code is out there if you want to use it a different way. There's a technical reference manual. And you can use it in a different way as such.

    But I think when you move to higher levels of abstraction, in my mind, you probably don't want to be dealing with these lower-level details. So having more standardized APIs and standardized approaches and having confidence that these APIs will do the job will essentially let us to move towards those higher-level abstractions.

    Recently I came across the problem. So when we are porting when we're in an X platform. So when they said the APIs will take care. So they came to know-- they have automated the DMAs so many, so simply they have given the DMA. But the queue is full. You got the point, right?

    Yeah, this is an excellent question. But I think this will need a bigger dialogue. Karthik is here for the rest of the day as well. So feel free or to sit down with him, discuss your views, and see you don't lose the essence of the hardware when you abstract. Probably we have time for one more question. Yes. If you can be loud enough, that's great. Otherwise, somebody will come to you with a mic. Yeah.

    So as the compute requirements increase in a dozen EV applications, day by day, we have new technologies or new requirements that are coming up. We need to develop them and integrate them. So with the change in requirements, with the change in hardware, with the change in development strategy, how to keep up with that rapid speed as a developer?

    Anyone want to take it? Too much is changing. How do we keep up?

    [LAUGHTER]

    So I briefly touch upon this when we talked about-- all the systems are developed parallelly. It's not that it's following a sequential approach, one. It's important, the emphasis on the CI/CD pipeline, because how the process-- if you could go to the keynote address, there was emphasis on standardizing the process within the organization and how the teams are working together, the informations are getting exchanged, and having the right approach in terms of system integrations and validation, integration strategy.

    So these are the key essential how you are going to work together. So it's predominantly going to revolve around the CI/CD, the DevOps operation.

    Sure. Sure. Thank you, Ramanathan. Any other questions?

    Ma'am, I saw you walking in between. I want to pull you in if you have a question [LAUGHS] there was a question as well. I think we'll take one.

    You think about the question. OK.

    Yeah. The-- OK, we have a couple of questions.

    Ramanathan, OK.

    Are there any parameters on which we should decide our redundancy of one SDV? If we have dual redundancy systems of [INAUDIBLE] after all, if the redundancy system fails, our human life will be at risk.

    At a risk, OK.

    So are there any parameters on which we can decide the number of redundancy system?

    OK, I'm going to repeat the question because you did not get a mic. Question is to Ramanathan. Ramanathan, you spoke about redundancy. Are there any parameters to decide this redundancy, like dual redundancy or a quadruple redundancy, so that we don't compromise on functional safety?

    Yeah. So when I was explaining on that, also I touched upon there are different thoughts which are evolving. Either the existence-- the co-existence of safety and nonsafety domain is going to be there in one controller or a multiple controllers. Second thing is that, as we speak, the functional safety standards is also evolving for the SDV perspective.

    So there, at this moment of juncture, it is predominantly going by the functionality and how redundancy you are going to build at this point of time. But the industry is looking towards the next generations. Like you saw, the SysML is coming with the V2 to adapt to the SDVs. The same is what's happening with the functional safety.

    OK, so that's your answer [INAUDIBLE] do you have a question for us?

    So my question is from-- for all of you. So the customer base for passenger vehicle is vast. So Asian customers for using SDV in passenger vehicle is your customer. But in like your commercial vehicle, your end customer is not a fleet owner. So the cost wise, how you are going to manage integrating SDV in your traditional architecture? Because it comes with a cost.

    So if I can understand correctly, your question is specific how passenger and commercial vehicles are going to adopt the SDV journey, right?

    Yes.

    So use cases are totally different, where passenger vehicles are more on the personalization. Commercial vehicle is more on the fleet. Fleet, wherever fleet is, they have-- they are like typical use cases for SDVs because they have a specific drive cycle, specific pattern, where-- and their drive cycles are also supposed evolving. Then this is a fit case for SDV.

    Sure. And I think we can continue these conversations. I've been cued in that we are completely out of time. So [INAUDIBLE] I know you're here, so we'll have offline conversations.

    Now, thank you so much for your attentive listening. And thank you very much to the four panelists for all the time that you spent with us this morning. And yes, I think it's over to Shishir now to take you through the rest of the proceedings, and then we come to the end of the first half. Yeah, so Shishir, over to you.