Making Software-Defined Vehicles a Reality
Kishor Patil, KPIT
KPIT’s experiences with software-defined vehicle (SDV) programs across various global initiatives have provided valuable insights into their dynamics and success factors. By engaging with diverse programs worldwide, KPIT gained a deeper understanding of the unique challenges and opportunities each presents. Key elements contributing to the success of these programs include robust stakeholder engagement, comprehensive planning, and adaptable frameworks that cater to local needs. To enhance the effectiveness of SDV initiatives, it is crucial to foster collaboration among international partners, leverage technological advancements, and ensure continuous learning and adaptation. These strategies not only bolster the programs’ outcomes but also ensure their sustainability and long-term impact.
Published: 26 Dec 2024
Good morning. And thanks, Jim, for making my job easy, very, very comprehensive discussion about SDV. What I will try to do is, basically, talk about our experiences. And based on that, I mean, we work with about 10 largest SDV programs, which are going in the world in now different parts of the world.
And I will try to bring some understanding of those and see what has helped or what could it be that can make those programs more successful. So I'm going to try and bring few things like that. And this I spoke about 2 and 1/2, 3 years back at AEK in Ludwigsburg, Germany.
And naturally, the time has gone far. And now many of those programs are in a advanced stage. And of course, we have also taken up new programs. So I guess I will try to share as much as possible what it means in terms of SDV program and its success factors.
I will skip this because-- so if you really look at the SDV goals and motivation, I always-- Jim put it very well. But maybe I may just say two things. One is I can say that Tesla brought this craze first. I must say that. And that was largely the software update through OTA. I think it has been around.
But I guess what that means is what-- that became the main thing. And I remember some of the people thought that 60% of Tesla valuation is because of the OTA. I never believed that. But I'm just trying to tell you that. So it was a craze which happened because of the updates, which can happen.
And the second thing is the software ownership, the way the OEMs were working, that they were working with tier 1's. And the whole system used to come from them. They had very little control over it. So if they had to bring any new features, it was very hard for them to make any changes and bring them to the consumers very quickly. So this is basically the two main reasons.
And of course, that needed ECU consolidation. That needed monetization possibilities. And there were very few companies-- I mean, there were companies who came up and said that they are going to have $10 billion revenues from services and some say $20 billion.
The real figures are far from that. The only company who has made some money there is Tesla, which is through charging infrastructure from the services, not data monetization but in some other way. So coming to that then going forward, basically, this stage went into a basic-- when we talk about ECU consolidation, the focus came on the architecture. How do you have the architecture which allows for the ECU consolidation?
And that's where many companies-- you remember they came up with this idea that they will hire those 4,000 people and build their own operating system and middleware. And almost every day, every two months, there was this announcement. And everyone was looking at where those 4,000 people are. But naturally, it's evolution. That's why we call it evolution.
And then people realize that what really is important is what the consumer says. So what is important for them is to do something which their consumers or clients will experience. And there are many areas which are non-differentiated but core, which can be taken from the tools companies or companies who build software products or other companies.
And that's when common SDV platform is something which started becoming-- people started thinking about it. It has not yet come. But I guess there is some progress.
For example, for us, we created a company called CODEX, which basically the idea is to-- it's a part of the Eclipse Foundation. So we really make it a lot of things. We make it open source and also make it available for the clients. And the integration becomes easy. Many other companies can really contribute. So some of those factors change from here.
Then software ownership is not, in the literal sense, everything. But it is more about the features. And of course, the cloud strategies, et cetera, we spoke about.
Coming back, fast forward this 2024, there was a rude shock people got from China in between. [LAUGHS] I think people realized they focus too much on building software. What was the main purpose of the software-defined vehicle? I talked about two. But there is a third very important part which was there.
Every time there was a new program, people used to get the whole software. Again, it was like a program. And everybody used to write the whole software again. And then it makes it more complex. Integration becomes more complex.
The costs are high. So that was what the problem was. So the idea was really to reduce the cost of software, instead of-- there was, of course, more things which were going to come-- but really not spend that money in developing again and again. But I think that's what people missed.
And we heard about what China did to some extent. But in my view, China did more on the non-software side more strongly. And then they reduced the cost. And they are now actually-- the software part, they are still maybe figuring out more, though, they are quite far ahead.
And the main thing where we saw is the user centricity, the experience, which has been created for a person who is in the car. And that has really the big difference. And again, I said something what can be felt by the consumer. And that's the focus which came-- and last but not the least is, how quickly the products can be developed? In two years.
I mean, some people are talking about 18 months. And many of them are still about three to four years. So that actually is what I would say the evolution-- it is still going on. In my view, it will take another one or two iterations before it really gets to a place.
All the OEMs in different geos are in different parts. So US companies are in a different place. European companies are in a different place. Chinese, of course, are in a different place. And I think Indian companies are in a different place. So it's different parts in the geos are at different place. So the good part is you can learn from someone and you don't have to make the same mistakes and you can take your own chances.
Just two things, I believe India is an interesting opportunity to innovate and relook at things. The consumer digital economy is big. So what you see about this consumer experience has happened because of the digital economy China has. And India has a very strong digital economy.
Then the second thing is the number of cars which you can call as utility vehicles or the larger cars. That percentage is increasing. So the benefits of SDV are some of those features. You can be very tangible in those kind of a thing. Electrification is growing fast. So that is a very, very important part.
And AI, I guess-- they say that AI capital of the world in terms of number of engineers working in these areas. So that is a big opportunity for India and many auto industries, I mean, are working in this area.
And last but not the least, we talk about all the global OEMs are here. They have their development centers are here. And they are working on these areas.
So this is what the other different aspects of India is. And that is why I believe there is a big opportunity in India. And India can be a different market and can be very interesting market even though it has started a bit late.
So if you look at what are the industry commitment for SDV transformation, I mentioned, I think, other than three to four companies in the world, like I said, everybody has moved quite a bit in this space. People who have not moved, they also say that they are under their part to SDV. But most of them have moved on to the SDV part.
But some of these, if you look at what is happening is they are trying to collaborate. Now, you see Hyundai is far ahead. I mean, ahead in the journey now, Nissan, Honda coming together for developing of the EV technologies and SDV or Volvo, Daimler setting up a center so that they can come up with a SDV for that segment, specifically BMW, AWS, or Hyundai.
So there are many, many changes which are happening. Same thing is happening in India. I guess I don't have to go through all the names. But Tata Motors is focusing on software on wheels. But Qualcomm, Maruti Suzuki, Mahindra, investing in competencies for advanced software, Ashok Leyland. So many companies are investing.
I personally believe the big opportunity for India is not to be very smart. First, we don't have to develop everything because there are enough things now available, number one. Number two, we have to learn from the mistakes, which people have done. That is the second part.
And I think if there is a better collaboration, which happens between the ecosystem, between the tools, and the other whole ecosystem of tier 1 service integrators, providers, solution provider, I think India can really catch up very quickly and have a very smart and affordable solution. That's what I think. I do believe there is a better chance and opportunity for standardization, which has to happen.
Either we have to adopt certain standards, clearly, or we tweak them for India. But for that, again, industry collaboration will be required, which you see is very hard in most parts of the world. But if you can do that, I think that will be great. China's success is based on that because the government led that collaboration. So if our industry can do to some extent, I think it will be very useful.
This I will spend some time. So Jim talked about some of this. But technically, if you see, there are different architectures, software architecture, network architecture, this.
And these were not really, if I were to say, aligning, or there was no coherence between these two for many cases I've seen. And this decides the network performance is another part is specifically moving to ethernet. The capability is basically limited having a right network. That was important.
Domain architecture towards service-oriented architecture, the cloud transition we talked about. Many companies, as I said, again, went for the whole development of software. Now they already have been working on these programs for a long time. I know there is always an innovation.
But there is always some work which they could have used or they can use. And that is possible because you can just move it in a certain way. So reusability of software is possible.
So as soon as you try to develop something completely new, that also creates a cost and time. Then the establishment of CI/CD/CT, we talked about that. Common data platform, cloud platform, validation environment-- see, this is very important because, I mean, I have gone to many large OEMs. And I have seen that they have cloud. They have everything. But the data does not travel very quickly.
If you have to access the data in the cloud in one centralized way, it is not there. So that's why we created something we call as data first architecture. And basically what it means is data has to really-- you think and design architecture based on how data will travel, apart from this. So I think that is a very, very important part.
And complexity in integration, we talk about this separately because I believe this is the largest problem. And even if you have a very good products, they are as good as they are integrated. So I think it is a very, very important to understand this part.
And the validation strategies scale is very different. Why this is different is the complexity changing, as we heard, the complexity changing. But not only that, the complexity will change to a different extent.
Now, people are talking about chiplets. If those kind of technologies-- I'm not talking about-- I've seen a few in some parts. So if these kind of things are coming up, their integration is much more difficult than the normal. There is a hardware integration. There is a software integration. So there are multiple things which will change.
So I think this complexity of technical has gone up multiple times. And operationally, the reason these have been created and not being addressed are two or three things. First is the organization structure. I think this is one of the most important part for the organization. Most of the large companies had organization structure. And then they had very senior people at, for example, PowerTrain.
They could not touch that because that was the largest-- that was the key technology at OEM. So they kept these departments separately. And that has really made a big issue. And actually what we need there is basically one program across the multiple programs. There is a more horizontal structure which is required apart from the core domain base.
The integration, we have seen that there is no one common integration department who is responsible for integration. My view is having that one part will be a significant-- will make a significant difference to the quality and effectiveness of integration.
And we have been talking to clients. Many clients understand that. Some of them have made that change. Some of them have created a workaround. But as early as possible, this can be done. I think that is the most important part. Otherwise, the integration becomes in pockets.
The infrastructure readiness, we talked about it. Process method tools-- people have-- and this is a bigger issue-- I think you talked about it-- that there are tools earlier. And the people are used to use them in a certain way.
First, there are different tools which are available for some things. And the second thing, the tools which are available, they are used to-- they use it in a particular way. So I think that training, understanding mindset is a very, very big thing. I think, plus that, I would say the mindset. Mindset is a big part in this whole transition.
And of course, the agile part and the issues of agile and understanding how you take an agile into a production program is still some work in progress. And again, I talked about mindset change, one team product mindset, solution orientation. This is a huge change for the OEMs. [CLEARS THROAT]
So what does this mean? So lack of integration strategy at the start of the program. I think this has been done more as a after thought.
What we have tried to do-- and I will talk about it-- and what we have seen, the very good benefit about is you start from the architecture itself. So create the architecture. We created what you can call as-- we also have, which we don't like to do this-- but we have some of the standardized frameworks of architecture because, frankly, there is nothing different.
What most of the companies do, it is very little. There is a difference. So the architecture, the point is the validation starts from the architecture.
And if you have a network and the software architecture and if you are in a position to validate it at the earliest, at what you call it, the left shift, that is the best way you can really understand how you can work with then tier 1's. So you give them something which is largely validated. And that is what goes to tier 1's. Otherwise, if it goes too early, then it goes to multiple things. And you see those problems at the end.
And if you really look at a four-year period, which was a normal-- if not for most of the vehicle program, half of the time. 40% if not half of the time goes into validation and getting the quality built. So if you do this, in my view-- and this we have proven in some cases-- 12 to 18 months of the saving in the vehicle program, which is, I think, the biggest saving you can get.
And I think this methodology is very important. This is not only-- this is driven from the software and architecture but, more important, from the way it is operationalized across the value chain with the suppliers, et cetera. While the hardware and architecture drives it, it is also about how you actually make it happen.
So there then there is a compromise in the quality. OEMs not having appropriate process structure for the integration-- I mentioned about not having centralized this part. Absence of virtual integration, now, there is-- again, we started a virtual program five years back with a large OEM. And they have made a significant progress in this area.
Then, of course, many companies are getting there. But this virtualization and the validation integrated approach is a very critical part. That can really bring the efficiency. And I think that is a very, very important part in the virtual part.
And so the integration, as I said, it is-- the complexity is so much because of the different technologies which are coming, different softwares which are coming, the semiconductors, what they are doing. Everybody is trying to do something new. And new technologies are coming. So the integration is getting difficult.
I really am thinking about the nightmare years, for me. It is going to be from 27 to 30 because when most of this program will come for the realization, it's going to be really a nightmare because this is the first cycle they are going through. I am sure there will be much better at the second time. When the first time they come, I think it is not as easy what may happen.
And so the delays, if you look at it, I think we talked about six months is a very optimistic-- I think it must be the-- generally, all the programs are delayed by one to two years for most of the OEMs. And that is one of the reasons I talked about is the validation is integration. Validation is one of the significant part and architecture. These are the two points I would call it out.
So this I talked about. Again, I will not spend too much time, again. But this is the data-first architecture, architecture is the option or is the approach, which is very, very important. You can start with what you call a blueprint or something, which is really-- that really helps you to start very quickly.
The workflows are different. That's what I am saying, to really adopt those workflows. That is very, very important. Then create a POC for architectural specifications.
So what we created is the complete simulation or complete validation process, actual physical validation process to validate the POC not only for just making it happen but also from the performance, which is very important. Otherwise, you go far away and then see that you are not getting the performance. And it also changes from which chips you are using, which controllers you are using. So I think doing that ahead of time is very, very important.
And then, of course, we talked about-- these are the two most important. Then OpenAI API or scalable middleware-- the middleware is very, very important, scalable middleware. Again, there are a lot of changes which are happening. I think for a long time, we had solutions which were there, which came out of Europe. And they stayed there for a very long time.
But there is now possibility of a change. And I talked about what we are doing today. But I think it will go through multiple changes. I mean, while AUTOSAR will continue to dominate for some time because it is there and it is there, the integration challenges. There are solutions already. We are basically creating what we call as performance stacked, which is beyond AUTOSAR, non-AUTOSAR solutions, which will become relevant.
Many Chinese companies don't use AUTOSAR. And it reduces the time for the integration architecture. They reduce that. I'm not saying it is completely proven. But there is a thing which will move in that direction. So I think that is one important part.
Open innovation-- the innovation will be key for different people, different client. And as you know, we talk about having a software program or a vehicle program which becomes refreshed because of having the ability to update it remotely. But similarly, how can you add features which are not necessarily only in your organization? If somebody comes with a very smart application, that open innovation is very, very-- would be, again, a very important part.
And I think that if you have a good APIs, scalable middleware, I think that is absolutely what can happen. And third thing, which is very important in the middleware part, or this part is separate, ease of development from complexity of deployment.
I think because it has been written by software developer, a lot of this middleware has been developed for ease of development. And the challenges come in the deployment. So how do you really have this middleware more for the deployment is very, very important. Then the integration issues will reduce.
And right now, most of this, including us, I will say, in all honesty-- and initially that was the approach. Now, when we moved, based on our experience, we moved towards how we can really reduce the complexity of deployment.
So there is always this issue where people think we are investing into software, SDV. What is our return on this? And whether it is going to be beneficial. Why do we have to spend billions of dollars in this investment. Number one, the basic concept of SDV is to reduce software spend.
Over the period when things materialize, you will have a very significant-- I would say 60%, 70% of our platform, which will be ready, 30%, 40% new things which will come. New integrations will come. Integration will continue. Validation will continue.
But there is some-- new features will come or new innovations will come. So I think that is the point. But if you really look at it, this-- basically, what we are looking at is reducing time to market, how quickly you can really bring a new feature through the SDV, how you can reduce the vehicle program timeline, as I said, two years, maybe less or maybe 30 months.
So that is very, very important, the user experience. Outside the vehicle, how do you really integrate things and create the user experience? It has not happened yet.
I mean, naturally some tech companies still continue to dominate that space. But OEMs wants to have their own user experience because they want to really have that personalized vehicles, personalized experience. And I think that is going to be a very important.
I think after-sales revenue is going to be a very big area and still not as much explored or worked on. And this after-sales revenue is-- that can become very big. So one of the main thing, for example, if you look at it-- and this will be different in India, I'm aware. But I'm just giving you a global example that when you have the dealers and distributors, the money was getting distributed different value chain.
OEMs basically wanted to take back most of that. And I know even in a non-passenger car, even in commercial off highway, I have seen some of my clients done it, at least, at that level. So the point is that is another part.
But you would want to do it without losing touch with the consumer. I think that is really the key part because the benefit you get from the distributor, there is a connect with a client. And how do you do that? When you are actually doing it more virtually, or I would say, relatively virtually. So I think that is important open innovation I talked about.
And the cost-- I think the biggest issue is about the cost and cost of actually how the design of the vehicle happens, how the design of the software happens. And I must tell you, these two are not very different. I mean, they are different. But I'm saying the software design and architecture can influence the overall cost of the vehicle significantly.
And the difference-- that's why if you do this ahead, when you are in the planning stage, that is your best chance to reduce the cost. After that, it is only incremental. And I think that is the main thing which one has to see. And that's why I think the SDVs will go through two or three changes. But I think this is going to be very, very important.
On the left hand side, we talked about virtual engineering, software uses, middleware. So I am not going to touch that. [CLEARS THROAT] I don't want to spend time here. But I just want to tell you that I have just taken two clients where we have taken the whole program largely. And they went through the development cycle.
And in this process, we realized many things. And that is what I have shared with you is this. So for example, Honda is a very large program across all the domains. And the way it is, it is jointly accountable for platform and feature development, software integration, and then the direct sourcing to tier 1. So it is driven like that.
So Honda has told their tier 1 to work with this consortium. So I think this is how it is working. That will reduce the cost significantly. I mean, I can only tell you that in another OEM in Europe-- because another part of the SDV-- what is the reason is disaggregation of hardware and software, so separation of hardware and software.
So in one of the case in Europe, we actually-- for a charger, we actually separated hardware software, took the full ownership. The OEM has come back. We thought we could give 30%, 35% saving. The OEM has come back to us and said that they have got more like 45%, 50% saving in the cost. So this is significant savings, which are there.
So this part is very important because you get the SDV. You see the architecture. But you have to achieve that separation of hardware and software. And if you can achieve that, then that's why I was saying the cost will come down because, even today, I see all the programs.
Many of the OEMs have not gone for hardware, software separation as much because they are used to doing that. And that was their, if I were to say, safe factor because they were always used to do that. So I think that is a big hit, this part.
And integration test house, development environment, location, different parts of the location, China, India, Japan-- so I think this is what makes it different. And that experience I am trying to share with you.
The second is Renault. Renault went in a different way. They had a strategic partnership with Google. So their operating environment is very different. And then the development model is different. So I just wanted to bring out two different examples. As I said, we work with about 10 of these programs.
So I just want to say that-- and you talked about it-- is we have a long lasting relationship with MathWorks. Actually, almost all the processes we work with our clients. And these are multi-year strong partnership through mutual programs with the client. We are not talking about between us. It is more for the client.
And engineering, productivity, quality improvements, training joint pilots in SDV area, thought leadership, which is very important. Participation in policy space, advisory board, MathWorks advisory board. So there are many things which we continue to do. And I think that helps us as well as our client, more importantly, and the tooling certification.
So I believe there's a very meaningful role MathWorks plays. I think the importance is to understand how to use it more and more effectively. And again, I already covered-- so these three ADAS, virtual engineering and PowerTrain--
I think the overall impact is very significant in terms of faster time to market and accuracy. We believe that these are the tools which can get integrated with other tools or other software development you have done or mainly your development methodology that brings a significant benefit.
Also, in terms of simulation, some cases, or a testing, I think in that case, many use cases you have. I think that is one place, also, where you can reduce a lot of time.
So coming to what I wanted to say is the success factor of SDV, in my opinion, one of the most important is the integration. And how you set it up as OEM for the integration is one of the most important factor.
The second is the tooling. And the tools are-- one is not necessarily available across the value chain. And there are new kind of tools which are coming. But we have to be very careful how they get integrated and works these-- of course, MathWorks has some role to play.
There are other tools beyond, in different parts. So I think this tooling is very, very important. And specifically, they are set for SDV. What we are doing ourselves is we created the whole set of tools which are required in validation, not necessarily software. I'm saying overall, which will be focused only on SDV.
And then we will integrate this with companies like MathWorks. So that is what will bring the best benefit to our client. OEMs are increasingly collaborating. That we talked about. Restructuring of the organization to adopt horizontal CI/CD/CT, virtualization, middleware is very important.
I believe the cultural change is the biggest change. And what we have seen is in some of our cases, when we have very large clients and very closer relationships like Honda or some of those, where they do send hundreds of people to our facility, they see how we work. And that makes a very, very big difference.
And the consistency of processes and methodologies tools, not only software but the way you work across is going to be important to realize this. I think we talked about this OEMs software integrators, process tier 1's cloud ISV semicon. Things are changing. And the complexity will just go on. I think it's a journey, again, together.
As a ecosystem, we can all work together. And I said to companies like MathWorks, KPIT, and the companies have a meaningful role to play. But ecosystem wise, [AUDIO OUT] really again feel that India is a great place where it is because we can use the experience of global here. And we have the ecosystem, which we can work locally to make that happen. Thank you.