For over a decade, Excelfore has quietly built the connective tissue of the software-defined vehicle before the industry had a name for it. In this candid conversation with CIO&Leader, Co-founder & CEO Shrinath Acharya and Co-founder & CTO Shrikant Acharya trace that journey from early bets on standards-based, end-to-end connectivity to powering OTA updates on the Tata Sierra and Hero MotoCorp’s two-wheelers. They unpack the engineering and commercial risks behind large-scale OTA rollouts, why proprietary stacks eventually collapse under their own weight, how Features on Demand could reshape ownership economics for price-sensitive Indian consumers, and where the real vulnerabilities lie in vehicle-to-cloud pipelines. The result is a rare, unguarded look at what it actually takes to scale SDV in India.
CIO&Leader: Excelfore has been working on SDV platforms for over a decade—well before the term became industry shorthand. What did you see earlier that most OEMs were still missing?
Shrinath Acharya: Whatever the vision was, and is today as well, is really the end-to-end connectivity. And that’s what we called it when we started the company. And we said that, you know; right now, you have certain connectivity inside the vehicle and certain connectivity in the cloud. And that is not something that will eventually sustain. You really need end-to-end connectivity. And that too, not just proprietary, because our philosophy is that proprietary does not scale.
You need standards-based connectivity in the cloud and inside the vehicle. So that’s exactly what we started doing. The initial deployments were clearly inside the vehicle because the cloud people either didn’t understand or didn’t want to pay. But now it’s very clear that they are willing to do both and do understand what SDV is. So, that’s how we evolved.
We have millions of vehicles deploying the in-vehicle stack, which is automotive Ethernet primarily, although we support all stacks inside the vehicle. Then, from the vehicle to the cloud, we have approached 10 million vehicles on the road. Our total deployment globally is approaching 19 to 20 million.
CIO&Leader: The Tata Sierra deployment is a significant production milestone. What were the hardest engineering and commercial problems to solve before OTA updates could go live on that scale?
Shrikant Acharya: I think the first thing to understand is the standardization philosophy itself. Traditionally, Tata vehicles have been driven by Bosch software. But in today’s environment, things have been changing, and relying on proprietary technology and a proprietary company is becoming difficult.
Even Bosch has become unstable. I mean, if you have read the news, they have laid off tens of thousands of people, literally, because of the changing landscape.
When you are wedded to technology, and you are making a change, that’s the biggest challenge. There’s a lot of self-doubt that happens when you make a change in strategy. Even though this was very painful and very expensive, when you make a change internally for what I call a decade-long rollout, it’s a major review within the organization. Somebody must take a risk, and it’s always a question of whose head will roll if this fails. That’s always the most difficult aspect. Doing the job itself is much less problematic.
But I think it was not just the OTA itself that was key here. It was OTA, then finding the problem in the vehicle and fixing the problem. Tata took a much bigger risk. It was nearly three times the risk. Not only did they implement OTA, but they also had to build data aggregation and actually enable remote diagnostics. That’s why it was a difficult undertaking. So, technology-wise, the decision was the most difficult part of this whole process.
Shrinath Acharya: We cannot apply the systems of the rest of the world to India for more reasons than one. I think there is also price sensitivity in the market. You have to be aware of that.
But, you know, we cut our teeth on OTA in China, which is also price sensitive. So essentially, we have a very good sense of what each geography needs. There’s a different business model requirement in China, Japan, Europe, and the US. Although we cannot classify Europe and the US similarly, they are still different. So, for us also, we cannot pretend that they are the same.
We try to be cognizant of that for India and other markets. We have to price things properly. Different pricing models possibly have to be adopted. Maybe these cannot be the long-term contracts we sign in the US and Europe. Maybe they need to have shorter-term contracts. We have shown a level of flexibility, which is very important for our OEMs to accept and get started.
Over time, I think this will get deployed across longer timelines and more models. Frankly speaking, as you may have noticed from the blog, we are just getting started. This was really the first launch for Tata. They see a very clear path to further launches because it’s based on a standard. We are one of the participants in developing that standard, and Tata can really imagine a vision where these standards can be deployed.
CIO&Leader: Hero MotoCorp’s adoption of eSync marks a meaningful shift—two-wheelers are now software-defined products. How does the SDV architecture differ when you move from four-wheelers to two-wheelers, and what does that unlock for Indian riders?
Shrikant Acharya: Technologically, there are two things about SDV. I think, fundamentally, you have to understand that the two-wheeler is not substantially different from the four-wheeler. The difference lies in the number of electronic control units (ECUs). Two-wheelers have fewer of them. Four-wheelers have more.
Fundamentally, the way orchestration happens is the same. I mean, you have a TCU, you have 15 ECUs or 20 ECUs, or you have 5 ECUs. Fundamentally, if you look at the architecture from a systems standpoint, it’s not fundamentally different. So, in that sense, you are bringing something that was meant for four-wheelers into two wheels as well.
How does this affect Hero? What Hero wanted was to be able to diagnose problems on the fly, in real time. And if there was a way to fix them, they would like to fix them as well. Now, that allows the product to become sticky because suddenly somebody says, “Oh, it got fixed.” So, he’s very happy. That simple outcome, even though it may not be too intuitive- the fact that it got fixed simply by calling and that he didn’t have to go to the garage and pay money is a leap of faith that the customer makes in the product.
Shrinath Acharya: One more thing I want to emphasize is the fact that two-wheelers, while looking simple, may sometimes be more complex. For instance, in terms of safety, you are inherently safer in a car than on a two-wheeler.
You may actually need better safety requirements in a two-wheeler. I think a lot of these things come together when you’re managing a two-wheeler versus a four-wheeler. Again, it’s a more simplified system in most cases because it’s a smaller vehicle.
That’s the way we look at it. We don’t look at it as a two-wheeler, so to speak, but as a smaller vehicle. Even smaller cars may be similar to a two-wheeler. That’s the way we look at it. But fundamentally, as Shrikant said, architecturally, for us engineers, it is very similar. We can deploy a complex model or a simple model. It doesn’t matter. We can do that.
CIO&Leader: Features on Demand is often discussed as a revenue model, but it fundamentally changes the OEM-customer relationship post-purchase. How are Indian OEMs thinking about this shift, and where are the friction points?
Shrinath Acharya: It’s an excellent question because the situation here is that, even in the US, I don’t want to pay for something continuously if I don’t need it. I think we must be sensitive to that. And it’s even more sensitive in India because, fundamentally, as I mentioned earlier, price sensitivity is an issue. Since price is an issue, you have to be careful about how you price it.
Just to give an example, let’s say I bought a car today, and then I need a better car, so I am selling this one and buying a better car. Then I buy an even better car and sell it. It’s a highly interactive, maybe painful, and expensive process for the customer.
SDV can actually solve some of that with Features on Demand. For instance, let’s say I buy a base car, and presumably it has enough hardware to support it. Then let’s say my parents are coming to town, and I buy a luxury feature for 10 days or so, so that my seats are more comfortable. It’s not as crazy a purchase as it would otherwise be.
And then, when they have left, I just don’t pay for it anymore. I can pay a much higher amount for those 10 days than I would have if I had bought the unit outright, but that’s okay. On a per-day basis, I have paid a higher amount, but I’m using it only when I need it. What ends up happening is that you can offer a menu of services—10 services, 100 services—but don’t bundle them and charge the customer.
Shrikant Acharya: If you look at it in a historical sense, nobody in India buys a big bottle of shampoo. They’ll go and buy those one-rupee packets. We have already been trained in what I call a microservice or a micro-feature adoption process.
So why front-load anything? It’s much easier to back-load it as the need becomes more visible, and then it’s not going to cost the customer much. Now, albeit it’s not the same as buying a shampoo sachet, the need comes through awareness. If he’s not willing to pay today, but awareness is built over time, he says, “I need it now,” and he pays for it at that point.
So, in that sense, subscription-based feature rollouts are going to be popular in India.
Shrinath Acharya: One more thing to add—just take an example. When the initial phones came out in India, there was a craze for ringtones. If you remember, and it may still be there in a sense, at that time it was an extremely profitable business for telcos.
It was not about offering 10 ringtones for ₹1,000. It was one ringtone for a few rupees. I could buy it, get rid of it, get a new one, and get rid of it. Everybody was doing it. I think that’s the kind of thinking we need to have. Don’t bundle 100 features. Offer them à la carte.
It will have two benefits. Customers can definitely choose what they want. You will get better feedback on what customers really want. If they choose only four features out of 100, then you can put all your engineering and marketing efforts into those four features. Forget about the other 96. Or, if people still want the other 96 features, you keep them, but you don’t spend as much time and focus on them. Make sure these four are well supported. The others are still available, people pay for them, and you can price them differently as you decide.
It becomes extremely profitable if you do it right. Do it wrong and say, “Hey, my price is going to be higher,” and people will say, “I cannot afford it today.”
But maybe I can afford it tomorrow if you sell a car that is actually upgradable. I may not really be able to afford a luxury car today, but maybe I can afford it in two years, and I’ll pay for it.
I think if you have those capabilities and the technology to support them, what we do essentially is combine Features on Demand with our OTA platform to create a full-service setup where customers can seek out features.
The salespeople at the OEM level can define what features they want to offer. We have both those capabilities, and then the whole thing can be sent down to the vehicle. Features can be updated and removed once they have expired. You don’t leave the software inside the vehicle where it can then be hacked or gamed; allowing users to access it even after the subscription has ended.
You have all those basic controls in place so that the OEM is happy, the customer is happy, and I think Indian consumers are not fools. They are sensitive, value-driven, and you have to address what they need.
CIO&Leader: India’s EV charging infrastructure is fragmented and still evolving. What role do SDV standards play in making vehicles interoperable with that infrastructure—and who needs to drive that standardization?
Shrinath Acharya: I’ll give you one example, and then I’ll move on. Shrikant can address it more completely, perhaps. Just imagine you have got 10 vendors providing certain systems to you, right? And how can they support you over time?
To us, I think standardization is the most important aspect of supporting it.
Shrikant Acharya: I think the biggest challenge for chargers would be hacking—somebody imitating, spoofing, and cheating to get more power out of that instrument and then moving on. So how do you deal with this?
Cybersecurity is something that will change almost continuously because, as new hacks are found, they will have to be corrected and updated. So fundamentally, you need an update mechanism in the charging stations to start with.
The concept of SDV is more about how it adjusts itself to the charging profiles of different vehicles. Different vehicles come with different sets of batteries. So that means the same charging process may not be advisable for every vehicle. There is a charging profile for a specific car or for the specific charger that is installed in the car. So, the system in the vehicle has to adjust to all of that.
Now, the other thing about charging vehicles is that, if you talk about the chargers themselves, they can be available at a public location like a gas station, or they can be installed at your house.
So how do you change the profile of a unit? It’s the same unit that sits in a public place, and the same unit is in your house. There will be some interface changes and other differences’, making it a different product, but the overall setup is the same.
When we talk about SDV, I think one of the challenges we all have is that we first must define what we mean by SDV. If you don’t define it, it just becomes a big mystery cloud for everyone. In that sense, SDV itself—the functionality as it applies to a vehicle—is not the same as what you apply to a charger.
CIO&Leader: You’ve spoken about the Make in India opportunity in automotive software. India produces world-class embedded and systems engineers—but is the domestic supply chain and OEM ecosystem ready to absorb and scale that talent into SDV production programs?
Shrinath Acharya: Fundamentally, if you ask whether Indians are good at software, I think globally everybody will say yes. So, I think that’s a non-issue.
The only difference is that, so far, they have been building software for others outside the country. Now you simply must redirect that talent and make it valuable for them to deliver to the country.
I think I’ve seen a big change, at least commercially. People think that way. In fact, I would say that 10 years ago, I would not have considered India an innovator. But with the Tata Sierra, you can see the progress in putting SDV on an ICE vehicle. I mean, that’s real innovation.
Innovation is happening a lot in small cars in India in particular. I think India is a powerhouse of software engineers, and I think they simply need to be redirected. Please go ahead.
Shrikant Acharya: If you look at history, you spend a lot of money as you update technology from time to time. Now, if you’re starting from far behind, you can literally leapfrog from where you are to where you need to be.
I’ll give you an example of telephone lines. While there were a lot of innovations in the US, we leapfrogged directly to mobile. Technology doesn’t necessarily mean that we also must follow the same learning curve.
Similarly, with software, you don’t have to follow that learning curve. We built software for others, but India decided not just to do OTA. I feel that when we implemented the SDV connectivity framework for Tata and Hero, there was not a single OEM in the world that had all of that.
To the best of my knowledge, nobody had everything combined together on the same platform, using the same APIs and extended APIs. It was a technology leap that, in my experience, I can say the world had not actually attempted.
As technology evolves, people become less risk-averse. Here, there was not enough technology to begin with, so they leapfrogged. I saw the same attitude in China, and look where they are today.
Shrinath Acharya: I am Indian by birth, but I’m a globalist. We are deploying these technologies across Japan, Korea, Vietnam, Germany, the UK—you name it. And we are finding that the “Make in India” initiative is not just a slogan. It is real and can be leveraged effectively to create world-class products.
Shrikant Acharya: But you also have to understand that there has to be political will and drive as well. Nothing happens without that because I have never seen industry define its own momentum.
When a government says, “This is what needs to be done,” it creates direction. If you look back five years ago, “Make in India” was considered almost a joke because there wasn’t enough infrastructure, enough vertical expertise, or enough experience in doing it.
But look at the landscape five years later. It has changed substantially. Look at the startups that are building in India—they are keeping pace with startups in the US.
A lot of things have changed. To some extent, the government deserves credit because it put a stake in the ground and said, “You will do it this way.” Industry doesn’t always follow the right course, but it does follow a course that gets set.
And for that, the government deserves credit.
CIO&Leader: eSync is built on GENIVI and AUTOSAR-aligned standards. In a market where every OEM has proprietary stacks, how do you make the case for standards-based architecture without it becoming a procurement conversation about lock-in?
Shrikant Acharya: First, I’d like to point out that you used the word GENIVI, right? We are nowhere there. I mean, GENIVI is old. In fact, GENIVI started this kind of open-source movement, but the challenges with standardization are many.
Standardization by itself doesn’t succeed simply because it’s good to have. The first question that will be asked about any standard is: How many are using it?
If you don’t have enough users, standardization is useless. Then the next question is: How robust is it? Because if you don’t have enough users; there’s no robustness.
Most standards never succeed because of that. AUTOSAR is a standard. If you’re interested, you can go and research it. It was a very good effort. I was there for a year and a half, tracking how they progressed. But one of the challenges they faced was that they had a lot of what I call educators who were testing it out, but no corporations were putting it into production.
The other thing is that standards usually have the document first, and the code comes later.
In the case of eSync, it was a code-ready specification, which means the code was ready as the specification was ready. One could actually track how the performance was on the system while referring to the specification. That allowed adoption to speed up.
The other thing you need is some luck. China did not have anything when we went there to educate people, and suddenly six or seven OEMs started using it. That really sets the stage for adoption.
Standards don’t become useful just by happenstance. There is some luck, there is perseverance, and there is a lot of what I call missionaries who must keep pushing until adoption reaches a level where people think it’s a good idea.
That is one of the reasons why eSync has been a success, while other standards that followed suffered because, although they were good to start with, there was no adoption.
Without adoption, standards fail.
And the final point is that they have to be low cost. If you have a standard and it comes with a high cost, nobody wants it. They’ll implement their own.
A standard is more like the icing on the cake. You have an implementation that is open, that people can actually refer to and build on their own. It’s low cost, and it has been adopted by seven OEMs, or 10 OEMs, or 12 OEMs. Then robustness comes by design because it’s now in its third generation.
That’s what gets standards adopted—not otherwise.
CIO&Leader: OTA updates are the most talked about SDV capability—but also the least scrutinized from a security standpoint. Walk us through the threat surface: where are the real vulnerabilities in a vehicle-to-cloud OTA pipeline?
Shrikant Acharya: Understand the point that every connection that is made is a potential threat. The connection from the cloud into the vehicle, and then from the vehicle to each device—each connection becomes a threat point.
Now, if the interface itself is not secure, that is the first vulnerability. All the legacy devices in a vehicle, like the CAN buses that run on the older CAN stack, are not secure.
They used to implement 40-bit security. That’s long gone—you can hack through that in a day. As I said, the whole security posture is only as strong as the weakest link. You have to secure the weakest link.
Typically, the cloud-to-vehicle connection is already secured through authentication, and then you can encrypt it. So that part is less prone to getting hacked. The communication inside the vehicle is much more likely to be compromised than the cloud-to-vehicle connection.
Inside the vehicle, if you bring the concept of authentication as close to the antenna as possible, then it becomes more secure.
Now, if you have the car calling the cloud, that becomes another security profile because you’re not broadcasting information. The car knows which URLs it has to contact, and you can update those URLs from time to time. The car knows where to connect, and people are not listening in on those communications.
There are many places like this where you can enhance security.
There are two aspects. One is the security of the transaction itself—you can encrypt it and authenticate it. The other is cybersecurity itself, which deals with threat vectors that emerge inside the vehicle.
We have been experimenting with cybersecurity updates, and I think our eSync pipeline allows multiple companies to integrate their own cybersecurity algorithms or threat agents into the vehicle without much difficulty. In fact, we worked with one company, and within three weeks they were able to demonstrate it at a show in New Delhi at the end of April.
Standardization is all about working with as many people as possible. What happens then is that a single company doesn’t have to spend all the money figuring out what isn’t right.
Standardization makes it easier to collaborate across companies. For example, with autonomous driving, there is a need for large-scale container updates. Working with the Autoware Foundation helped us figure out how container updates should work. Working with ASAM on SOVD helped us work on new service-oriented diagnostics.
The ability of standards to expand the scope of implementation and keep it current with the latest evolution of software frameworks and other technologies cannot be matched by individual companies.
Yet, despite all this, people continue to build their own proprietary solutions until they become unusable. Then they eventually fall back to standards.
Shrinath Acharya: I think one more thing here is, as Shrikant pointed out, just to reiterate that point. If you have a standardized process, everybody can benchmark themselves against it.
Otherwise, you have 10 proprietary systems, all claiming to be fantastically secure. Then they come together, and they may not be secure anymore because the interlinks are not secure.
I think there are huge headaches if you don’t standardize them. That’s why, in fact, what you’re asking about two-wheelers, four-wheelers, charging stations—the whole ecosystem must be standards-based.
It must be secure by design, not because one of the participants forgot to do something, leading to a failure and causing the whole system to crash.
CIO&Leader: Delta compression and selective update delivery are core to your platform. At scale—say, a million vehicles across geographies with variable connectivity—what does the failure and recovery architecture look like?
Shrinath Acharya: There are two aspects of failure recovery. One is that connectivity can drop because you are in a tunnel, or maybe the line is so bad. We have methods where we can actually recover from that.
Let’s say you’re downloading a big package—call it 10 GB, maybe an Android update—and you have already downloaded 5 GB when the line drops. We don’t start again from zero; we resume 5.1 GB, where it left off. So that allows for recovery.
On delta compression, we typically look at it from a dynamic compression point of view. We even have a pattern that the eSync Alliance addresses, which is to look at the target system and figure out what is best for it.
Now, what does “best” mean? Not maximum compression. What if it’s a very weak ECU? If you apply maximum compression, it may take such a long time to decompress that the customer becomes unhappy. Striking the right balance is really the core of delta compression. Please go ahead, Shrikant.
Shrikant Acharya: Compression is mathematical, so there’s no magic to it. But the same compression does not work efficiently on every dataset.
For example, datasets can vary from code and hex code to containers, LLM models, and even Android images. You cannot apply the same level of compression everywhere.
On top of that, when we talk about delta, delta means the difference. So you never send the whole code to the system or the car; you send only the difference between the last version and the new version that you want to update. That reduces the amount of data transferred.
But remember, compression is mathematical, which means it works based on redundancy. If there is not enough redundancy, sometimes your compressed package can actually become larger. However, you can be smart about it and make it work to your advantage.
Typical compression ratios are 50% or more and can go up to 99%. Compression is inherently important for conserving bandwidth on the communication channel. When you are dealing with a million devices, compression has to be part of the rollout because otherwise the economics simply don’t make sense.
CIO&Leader: Automotive Ethernet is central to high-bandwidth in-vehicle networking. How does that interact with the software-defined layer, and what changes when you’re managing Ethernet domains across a heterogeneous ECU environment?
Shrikant Acharya: First of all, Ethernet comes at different speeds. It ranges from 10 megabits—which is supposed to be a CAN killer—all the way up to 10 or 20 gigabits, which then becomes your backbone.
If you’re bringing in high-resolution camera data, 1 or 2 gigabits will not be sufficient. You need a much larger trunk on the backend.
The good thing about Ethernet is that whether you are using 10 megabits, 100 megabits, 1 gigabit, or 20 gigabits, the packet is the same.
The biggest advantage customers get is that there are no switching costs. You don’t have to put a gateway in between to translate protocols from CAN to Ethernet and from Ethernet back to CAN, while also managing the different bus speeds. Otherwise, you can get overflow and underflow issues depending on how data is sent up or down the hierarchy.
Ethernet takes care of that because switches are all you need. You don’t need gateways, which reduces overall cost.
The other advantage is that it is secure by design because Ethernet packets already have frameworks for security and encryption. You can carry the same security model from 10 megabits all the way to 20 gigabits without changing anything.
These advantages are inherent in the way Ethernet has been used in industry, and now they are being brought into large-scale automotive adoption.
The main challenge with Ethernet in a car is electromagnetic emissions. You have to figure out how to adapt Ethernet from industrial networking. In a Cat 5e or Cat 6 network, you have multiple pairs, but in automotive deployments you often use only a single twisted pair.
There are certain physical realities inside a vehicle that you must manage.
But Ethernet is really the direction in which cars are going. It increases transaction speed, allows you to secure ECUs better, enables stronger cryptography inside the ECUs, and removes many man-in-the-middle attack opportunities because you don’t need workarounds for slow devices communicating with fast devices.
Ethernet, in my opinion, is where everything is headed.
Shrinath Acharya: Just one more thing. While we already discussed passenger cars and two-wheelers, I think even commercial vehicles will move in this direction, just at a different rate.
Commercial vehicles are extremely price-sensitive from an operational standpoint. They justify investments based on per-mile or per-kilometer economics.
I think it will happen in a different way. And you still need a longer-term horizon because if you don’t invest today, you won’t have a product in three years.
You must start thinking strategically rather than only looking at today’s concerns and costs, which are important, of course, but we are trying to address them in the right way.
Shrikant Acharya: I think this is a great point that Shrinath brought up: invest now to reap the benefits later.
When a technology is already ready for adoption, others have already stolen a march on you. You’ll always be playing catch-up. But if you invest now, you’ll be ready.
Shrinath Acharya: Exactly. The Indian market is not as closed as it used to be. New entrants are coming in. BYD is here, MG Motor is here, and many other companies are entering.
The same thing will happen—maybe slowly and in a different way—but technology is coming in, and it can surprise you. Then you start scrambling and end up spending more than you should have.
You may end up buying what you could have built yourself.
The philosophy we propose is to use standards, reduce costs in the long run, but invest today.
CIO&Leader: AI-defined vehicles are the next inflection point being discussed. From a platform architecture standpoint, what needs to change in the edge-to-cloud data pipeline to support real-time AI inference and continuous model updates over the vehicle lifecycle?
Shrinath Acharya: Actually, what has happened is that even SDV has a different definition for each company.
AI-defined vehicles are even worse because, in a sense, SDV itself is not well defined, and AI-defined vehicles are even more ill-defined. So it really comes down to what it actually means.
We talk about AI-defined vehicles in many different ways. One is enabling faster development, faster integration, and finally faster and better deployment to reduce costs across the overall SDV development and OTA process. Another is using agentic AI inside the vehicle to further reduce the cost of supporting those systems.
I think that’s, at least, my view of how AI-defined vehicles are evolving. Perhaps Shrikant has more ideas.
Shrikant Acharya: If truck makers are looking at cost, AI may not come there soon enough because you’ll constantly be justifying the cost, and the customer is not willing to pay for it.
The justification for AI has to be internal to the company, the organization, or the car maker. If you can justify it internally through cost efficiencies, better problem resolution, and improved intelligence in the vehicle, then AI starts to make perfect sense because you’re trying to improve the vehicle itself.
But if you think the customer is going to pay for it, they’re probably not.
The other aspect is that cloud costs are going to become huge. Even if you collect data and use AI tokens to create inferences, you’ll run up the bill very quickly.
Where I think it will actually work is through tiny models. That’s how things will evolve for car makers. Car makers own the real estate inside the car, and I sincerely think they are trying to make that real estate work for them—not for Google or OpenAI. They really have to make it work for themselves, or they are going to struggle.
CIO&Leader: Remote diagnostics is often positioned as a cost-saving tool for OEMs. But the data it generates—usage patterns, fault signatures, behavioral telemetry—is extraordinarily sensitive. How is that data governed, and where does the line sit between diagnostics and surveillance?
Shrikant Acharya: I think it’s a great question.
First of all, identity has to be completely separated from the data itself. You should not know which specific vehicle the data is coming from. That’s something the OEM can do before the data actually leaves the vehicle.
The identity of the vehicle owner is stripped from the data, so it becomes data from a generic vehicle model behaving in a certain way.
The other point you mentioned is the amount of data being generated. You also have to be intelligent about how much data you bring out of the vehicle.
You cannot keep transmitting mundane data that remains consistently the same. You should focus on anomalies. Those anomalies become much more meaningful if you only collect them and then examine the surrounding data to understand how they are developing.
Intelligence must be built into every stage of the pipeline. Otherwise, you could end up spending a lot of money without achieving much.
Shrinath, would you like to add something?
Shrinath Acharya: I agree.
Fundamentally, when you’re talking about these kinds of systems being deployed… Let me address all the aspects of your question.
There are multiple regulatory frameworks across the world under which you are not allowed to link specific vehicle data back to an individual.
I’ll give you an example. Even if I don’t collect your name or your VIN number, if I know that you always travel through certain locations, I can pretty much infer where your home is.
You must think much more deeply about what can happen with this kind of data.
That’s why, as Shrikant mentioned earlier, we completely separate VINs and all personally identifiable information. Instead, we use individual vehicle IDs and secure identifiers. That’s how we make sure everything remains separate.
At the same time, you also must provide a better customer experience. Frankly, customers don’t mind sharing data if it provides value.
For example, if you’re stranded in a dark alley, you’re perfectly happy for someone to know where you are so they can find you. It’s not that people are afraid of sharing information—they’re afraid of sharing it with the wrong people.
So while regulations such as GDPR impose requirements, and many similar regulatory developments are happening globally around security and personal data, we have implemented those principles very thoroughly in our own systems to ensure that everything remains separate.
Another important aspect is data retention. When you look at data privacy frameworks, which we work on with many companies, you don’t have to retain data forever.
Detailed data can be retained for a short period, while summarized data can be retained for a longer period if that’s more useful.
So you have to be sensitive to how you process data rather than simply storing everything forever. Eventually, there may come a time when something gets hacked.
Look at what is happening with quantum computing. At some point, it may become much easier to break today’s cryptographic methods.
We have to be very sensitive to all of these issues, and that’s exactly what we are doing to address the balance between surveillance and diagnostics.