Vidya Rajagopalan of Rivian

Overview

JOHN: We’re pleased to welcome one of the leaders who is advancing software defined vehicles and advanced technologies in vehicles. Today in The Garage, the Senior Vice President of Electrical Hardware from Rivian. Let’s go!

JOHN: Welcome to The Garage. I’m John Heinlein, Chief Marketing Officer from Sonatus.

Meet Vidya Rajagopalan

JOHN: In The Garage, we bring together leaders across vehicle hardware and software, and today we have a special guest. We’re pleased to welcome to The Garage, Vidya Rajagopalan, who is Vice President of Electrical Hardware at Rivian. Vidya, welcome to The Garage.

VIDYA: Thank you. Thanks for having me, John.

JOHN: It’s our pleasure. And we were talking that you and I met many years ago. We figured it was around 15 years ago, in 2009, where we worked together. I was at Arm at that time, and you were at Xilinx working on their Zynq. And you helped found and create their Zynq product line which is really unique. I wonder if you can start by telling us a little bit about your background and maybe that product line where we first met.

VIDYA: Oh that’s great. So it’s funny because when we both met, neither one of us was in the automotive business. I was at Xilinx. I had actually gone there, to help their transition. Xilinx was known as an FPGA company. And they realized that for their growth, they really needed to expand their, you know, footprint. And I was brought in to help them build their first SoC product line. I helped launch the Zynq product, which interestingly– and I didn’t realize at that point probably what started my journey into automotive– one of the earliest applications of Zynq was in the ADAS space for the front cameras. But I helped build the Zynq SoC line, which really was a big transition for Xilinx. It was an Arm-based system, and we worked with you on the Arm pieces, the IP. And it changed the whole story for Xilinx because it was really software programmable devices that could just boot up. You know, we provided software, you know, from Linux and really helped our customers with a ready made system-on-chip. And then really, they could put their differentiated secret sauce on the FPGA.

JOHN: Right. It’s almost one of the, kind of early precursors to software defined vehicles, in a way, bringing software into the hardware in new ways, I think.

VIDYA: That’s right, that’s right.

JOHN: Now after that, you went to Tesla for a while.

VIDYA: That’s right. So, you know, I had spent my entire career… I started my career building microprocessors at a company that most people probably don’t know right now. It’s called DEC, was called DEC.

JOHN: I worked at DEC years ago as well.

VIDYA: Oh you did. Okay. Digital Equipment Corporation. And I worked there on the Alpha Microprocessor, which was actually a pioneering microprocessor at that time. And I spent my really early part of my career doing microprocessor systems SoCs. And after Xilinx, where I had a, you know, really fun ride building out the whole Zynq product. I was looking to do something different, and I wanted to do something that potentially, you know, brought together some of the things that I was passionate about. And one was climate and the other one was AI. And I saw Tesla as a place in the automotive industry, which was undergoing this remarkable disruption as a place for those to come together. So that’s what, you know, brought me into the automotive space, a passion for climate change and really to address climate change.

JOHN: That’s great. I mean, Tesla did a lot of incredible, I would say, rule-breaking things, you know, trying things in a new way that hadn’t been done before. But now you’re at Rivian and you’ve been there several years. Tell us about your role there, and your scope of responsibility.

VIDYA: That’s right. So I’m at Rivian. And what I do here, I lead the electrical hardware team at Rivian. So electrical hardware is all things electrical, really. It’s a loose name for that. It’s down to the low voltage devices. And more recently, I’m also running the the high voltage side, the powertrain side of the electronics. That includes, you know, the low voltage side includes all our controllers, ECUs, includes our wire harness, includes really every device that we have on it that’s electronics. So the displays, the audio, you know, the whole-

JOHN: Nothing important [sarcasm!]

VIDYA: Nothing important. It does make the car move, I guess.

JOHN: It’s incredible. And you’ve got… we’re going to touch on almost every one of those aspects, I think, in today’s conversation.

Surprising fun fact about Vidya

JOHN: We also like to get to know our guests at the beginning. You have to tell us a fun fact about you.

VIDYA: All right. So I have to fess up. I was not one of those people who, you know, grew up dreaming about cars or played with cars or had car posters in my room. If you told me about 15 years ago that had been the car business, I would have laughed outright. What brought me here was really my passion for both technology and really, as I said, addressing climate change. So people always assume when you’re a car company that you know you’re a car nut. I got to fess up. That’s not what got me here.

JOHN: I think my situation is the same. I always like to match my guests. And I would say my background is exactly the same. I did microprocessors, I worked in hardware, computer architecture, many different things. I never expected to be applying my skills to automotive. But as you mentioned, one of the things– two major things coming together in automotive– one is incredible technology integration that’s happening in automotive. And then second is green…sustainability. I think those are both excellent. It’s one of the reasons I’m excited to be in this space as well. That’s very exciting. I’m also especially excited to have you here because I’m such a huge fan of Rivian. I’ve been driving EVs now for, I think, about 12 years or something. And my current car lease is about to end, and I’m absolutely looking forward to getting a Rivian for my next car. So I’m very excited about that.

But also the incredible engineering you guys have done. The R1 is a groundbreaking platform in and of itself, but then you’ve just announced and we’ll probably talk extensively today about the generation 2 R1, which has incredible innovations from end to end, many of which you were involved in. You also announced…Rivian also announced the R2 and other models after that coming in, you know, the year after next.

The mindset shift making an SDV

JOHN: So there’s incredible innovation coming from Rivian. And I think you’re such an emblematic of the innovation in the industry. So we’re so happy to have you here.

So as we think about the shift to SDVs– and we talk about many different aspects of the shift to SDVs here in The Garage. But I think it’s not one change that helps you get to an SDV. It’s not like you flip one bit and all of a sudden now it’s an SDV. It’s an entire mindset shift of how you design the vehicle, how you design the hardware, how you design the software, how you design the networking. And one of the other things that’s so impressive about what the work you’re doing at Rivian is, I think you’re really showing how all of that can be done, especially with this recent change with, R1 to R1 Gen2.

ECU Consolidation

Your first generation R1 was super impressive, but the next generation is taking it to another level. So let’s start maybe with the first of those aspects. And it’s also kind of my personal favorite, which is ECU consolidation and integration. Because you can’t have an SDV unless you’re fundamentally sharing hardware. One of the defining factors of the opposite of an SDV, of a hardware defined vehicle, is one box does one job for forever and ever. But that’s not software defined vehicle. Software defined vehicle has to have one box doing multiple jobs, sharing compute, isolating workloads across everything. You’ve done incredible work in Rivian. Already the Gen1 R1 product was 17 ECUs, which is already much smaller than a typical vehicle. So already delivering on SDV. But in Gen 2, you just announced a few months ago, you’ve reduced that to only seven major ECUs, plus a few small other ECUs. Seven ECUs. That’s incredible! Tell us about that journey, and some of your philosophy on how you got to that point.

VIDYA: Okay. So first of all, I’ll say we’d be delighted to put you in one of our tri-motor or quad-motor vehicles. So whenever you’re ready, reach out.

System level thinking

VIDYA: Yes, you’re exactly right. It’s not just about, you know, how do you get a software defined vehicle? It’s not just about, you know, saying, I want to build one, but it starts really at the hardware . And it really starts even before you build hardware. It starts at the system concept. So you start out from the very beginning. And that’s, I think, what differentiates us. We start at the very beginning thinking about the entire vehicle as one electrical system. And really everybody says a car today is, you know, a computer on wheels. It’s not one computer, it’s a networked set of computers. Very diverse computers, in fact. If we look at the diversity in type of computer, you know, you have high performance compute, you have low, not that high performance, but real-time compute. You have really the diversity of compute that you don’t have anywhere else. Or actuators, sensors, all of that together.

JOHN: And safety-critical systems too.

VIDYA: And safety-critical, and security-critical.

JOHN: That’s true.

VIDYA: Because you don’t want anybody taking over. So it’s a very complex system of many complex sensors, actuators and compute types. And you have to look at it as such as one big, you know, system. And we look at it from a clean sheet of paper approach. And which is what I think traditionally OEMs struggle with, because when you buy a box from somebody else, what you’re trying to do is, how do I put the boxes together? And it’s never in the optimal way, because you cannot put a bunch of, you know, it’s sorting sort of bottom up, which doesn’t work. And so we look at it from a clean sheet of paper. Look at all the tasks that we fundamentally are trying to do. Figure out what kind of compute we need for those. And then we also look at really – as we said, we talked about sensors and actuators – all of them have a natural point in the vehicle. And we look at, really obviously, you want the computing— or even not the computing, the I/O – to be very close to the actual sensor or actuator. Because one of the big problems in vehicles or the mass in vehicles comes from the wiring. So we look at it as a really complex system that you optimize across many, many different, vectors. Right?

So when we launched Rivian, our goal was to get a really compelling product out to our customers with the best technology out there and the right trade-off for us at that point was a domain-based architecture, which is already one level of consolidation above what many other OEMs use. In a domain-based architecture, you have an ECU or control unit per group of, or per category of functions. So for example, we had 17 ECUs – in-house ECUs – that control different function categories. For example body controller, that would control lighting, doors, wipers, things that attach to the body as it describes. Another controller for vehicle dynamics. And all of this, what it really enabled us to do was have dedicated software teams that worked on one controller at a time, and it was a very efficient way to get a product out. And a compelling product, not just any product.

And as I said, again, you know, prior OEMs would have had many controllers doing the job of one of our domain controllers. So that’s how we started. We came out, I think… And also I think even from the very get go, and I should probably talk about that. Our goal was always to be vertically integrated. Our intent was never to rely on hardware pieces from different suppliers. So that was very clear to us from the get go.

Building systems from merchant silicon

JOHN: Right. I think while you’re taking processors, generally speaking, from outside the system engineering and putting those into sort of computers, as people call them, you’re doing a lot of that in-house.

VIDYA: That’s why we did that. Yeah. So that was always the intent. We buy merchant silicon but we integrate it in systems. That makes sense for us.

JOHN: Yeah, I think it’s a smart trade off too, because you don’t have to reinvent the wheel. There’s a lot of great compute out there, but the system integration has got to be fit for purpose.

VIDYA: That’s right. Exactly. And even though it’s fit for purpose, the thing I would say is we build it to scale. So we have the same ECUs that are in our Amazon vehicles, we call it the EDVs, and they’re the same ECUs that are in the R1S / R1T platform. So even though they are purpose-built, they are built to scale. And if you look at the EDV, which is a really big vehicle, and the R1, they’re very different.

JOHN: Right.

VIDYA: And we can really service both with one piece of hardware.

JOHN: That’s one of the benefits of software defined vehicles is that you can have the underlying foundation be the same, but you can customize whether it’s accessories or peripherals or things like that.

VIDYA: Exactly. Yeah.

Domain to Zonal shift

JOHN: That’s great. So… And you mentioned a domain-based architecture. Now as you’ve gone to the second generation R1 platform that just came out, one of the things you’ve done is shift to a zonal architecture or shift more fully towards the zonal architecture. Can you talk about that evolution and some of what that’s enabled you to do? Because the wiring simplification is really compelling, that you’ve been able to achieve.

VIDYA: That’s right. So you know, we are as I said earlier, a goal for Gen 1 is to get compelling product out quickly. And then our goal for Gen 2 was how do we optimize further? And the optimization, a lot of it has to do with improving manufacturing, reducing mass. It’s not many… some of those, you know, there’s some optimizations that are obviously visible to customers, but a lot of it is actually not even visible to a customer. If you look at the R1 Gen2, most people would not be able to tell the difference from an R1 Gen1, unless you’re really an expert, you can look at the difference in the cameras. But it was all very deliberate because it was… we migrated from the domain-based architecture, to a zonal architecture, which allowed us to go from 17 ECUs to 7 ECUs. That, you know… a nd why does that matter? It matters really, from the point of view of, it helps us reduce mass by 44 pounds. We reduced 1.6 miles of wiring, which is huge, which for an EV, mass is really a big, big contributive range. And then even having fewer wiring means fewer wires you have to make connections in the factory. You need fewer people, or you can finish building a car sooner. So really, these optimizations, many of them which are under the hood, have a lot to do with making Rivian be more efficient in the manufacturing process. Use the battery pack more efficiently to get more range. So some of these are not really visible to other people, but they really, really make the vehicle much more efficient along the way.

And we do have other optimizations for performance. For example, ADAS. We up-leveled our compute significantly. But the key about, you know, why don’t we do zonal architecture from the get go? It’s not like we didn’t know we could build one. But there’s a lot of software complexity in actually making that happen. And when we had the domain based architecture before, it was the fastest way for us to get going. And that was important for a company our size to be able to do that. Because as I mentioned earlier, you had a team working on the thermal management module. You had another team. When you have a zonal architecture, you have all these different functions. Each ECU now in its own architecture works on the physical space, at least the I/O portion of it, works on the physical space around it.

Which means, you know, in the old days – I love to take the example of lighting – you know, a lighting controller would have control lighting all over the vehicle. So you’d have wires snaking all around the vehicle from one point. In the zonal controller, the zonal controller nearest the physical light that’s close to it is the one that controls its I/O. But then that means to actually get that hardware simplicity, your software complexity went up. So now you have every zonal controller capable of handling lighting. And now you have multiple teams, you know, working on different domains. Now actually working on the same physical CPU, which means they have to learn to load share compute on the microprocessors. So there was a reason we didn’t start from the get go, but this really now enables us to really build a much stronger hardware foundation, which helps with cost, mass, you know, a lot of other benefits, sustainability, all of that.

Zonal architecture of Rivian R1 Gen 2

JOHN: So this shift to zonal architectures, and we talk a lot about that on the podcast, it’s really compelling for the reasons you mentioned. You have three zones, front left, front right and a rear zone. But you also have four major compute ECUs as well, one for infotainment and autonomy, sort of the navigation and ADAS, one for battery management, one for access control, and then you’ve got a special one for the NFC around doors. So you still have some very high performance compute blocks, especially for example, the one which does infotainment and autonomy, which has incredible performance. So this is based on Nvidia Orin processors, two Nvidia Orin processors, that deliver 250 TOPS. 250 trillion AI operations per second, which is incredible. Tell us about, how you made the trade off of those high performance ECUs and that design in-house.

VIDYA: Absolutely. So I think, you know, the zonal computer largely, you know, pertained to sort of things like body functions, dynamics, thermal management.

JOHN: Sensors, especially.

VIDYA: Really sensors. But I would say non-ADAS sensors because, you know, you do have so I mean so many different types of sensors. So we put all of that functionality which is often real-time sensitive in the zone controllers. Not all of them are, but many are real time sensitive because you have to respond in real time. And then we deliberately chose to keep the infotainment and ADAS separate. Well, you know, because they’re very distinct from what happens in the zonal controllers. The infotainment serves up all the experiences, you know, that the driver or passenger may interact with. The telematics, you know, connects the vehicle to the web or the internet. And then the ADAS is sort of another very high powered system, which really takes all the information from the various sensors. You know, we’re a multimodal company.

You know, we use radar, cameras, IMU, GNSS, all of that. And then the ADAS obviously processes all that information and controls the actuators. So both infotainment and ADAS are very complex, and they really have high compute needs. The infotainment because it has to serve up all the rich graphics. Very different types of needs.

So it was very clear to us zonals were one bundle. Infotainment and telematics was one bundle. ADAS was one bundle. Even though we physically put the ADAS and the infotainment in one box. And then vehicle access is just very unique. It’s not as complicated an ECU as some of the, you know, infotainment and ADAS, but really it needs to be located in such a way that it can sense people approaching. So it’s actually for that reason, a unit of its own. And similarly with the door handle ECU. And then we have a battery management system which is really tied to the battery pack. You know, we offer two types of batteries. And so therefore it really comes assembled with the battery. And so it’s a discrete unit of its own.

JOHN: So it’s a really… I think it’s a really sensible smart engineering trade off. Right? Where you’ve got the zones doing jobs physically close to things, real time sensitive, wiring length is sensitive. But then these high performance compute – generally speaking – high performance compute modules doing these other dedicated purpose things.

Vehicle networks and automotive ethernet

JOHN: Talking about vehicle networks. And earlier you said you were able to reduce 1.6 miles of wiring inside the vehicle, which is a staggering amount and 44 pounds, I think you said, of wire. It simplifies the assembly. It simplifies the weight, of course, of the vehicle. You’ve also changed networking technologies because I believe the backbone of your vehicle is automotive Ethernet. But then within the zones, talking to the sensors can still use existing protocols, things like CAN or LAN. Can you talk about some of the networking in your vehicles?

VIDYA: Sure. And so first I should clarify, the 44 pounds was not just from the wires, also from the ECU consolidation.

JOHN: Of course. Okay.

VIDYA: Because you know, enclosure reduction itself gives you quite a bit. So yes, absolutely. We always actually even on Gen1 vehicles, had automotive Ethernet. But I would say there is more automotive Ethernet in this generation. It’s always… It was a backbone before, but it’s a maybe stronger backbone this time around. And I think, you know, ethernet is remarkable for all the reasons, you know, everybody knows and loves, you know, the software stacks and the ease of communication. The bandwidth, obviously, but it doesn’t… It still is not at the point today where it can be the communication medium everywhere. CAN and LAN really, you know, are cheap, are simple. And the biggest thing they have going is they’re a multidrop capability of CAN. Whereas, you know, with Ethernet you really need to drop in switches everywhere. I know there’s new technology with Ethernet– the 10-base T1S. But you know it’s not there yet where we need it to be. So yes, we use a hybrid approach. We use Ethernet as sort of a strong backbone for the bandwidth. We also use the, you know, time synchronization capabilities of Ethernet. But then when it comes down to communicating to, you know, actuators depends on the types of actuators and sensors. Some, for example radar still works very well with Ethernet, but some sensors and actuators, we still largely use CAN and LAN locally. Right. So that helps us keep the CAN and LAN more local to the zone areas. And not all in… We do have CAN over all the vehicles. It’s still there. But not as extensive as in previous generations.

JOHN: And I assume then that that must mean you’re still sending some signals over Ethernet that are safety critical, right? Because you’re leveraging time sensitive networking for some safety signals over Ethernet.

VIDYA: Right. And I think it depends on how you classify safety, like things like airbags, you know, communication, all of that is happening on dedicated communication from sensors to the airbag control units, and is happening on specialized wires. But yes, we do definitely use, you know, for example, I pick again, say, radar input or something else would go down an Ethernet. Yeah. But we have a very robust safety architecture. We look at it again, as I talked earlier, the advantages of having a…designing the entire vehicle architecture as a system. You know, we look at the functional safety decomposition of the whole system of the vehicle level and make sure it’s very robust.

Software architecture

JOHN: Well, that’s a perfect pivot. Let’s talk about the software architecture more generally. Because with this philosophy of doing a vertically-integrated approach, you’ve had to think holistically. So tell us about some of the trade offs and some of the things you’ve done there.

VIDYA: Absolutely. So I’ve talked a lot about the hardware because that’s what, you know, my teams work on. But our software team has really done a remarkable job in this regard. Because we don’t use any of the industry offerings such as AUTOSAR. We really built, you know, we look at it two ways. If you look at it, we build… Our zonal controllers are built on a very robust in-house, system that the teams have developed and that’s given us a remarkable amount of agility in terms of how quickly we’re able to develop features, develop hardware, test and bring it up.

And it’s really based on top of Free RTOS, but we really added a lot of layers to it. And, it has been a very powerful tool for us. Similarly, on the autonomy side, we‘re, you know, while we use the processors from Nvidia, we really believe strongly in building the application and the middleware layers and all of that.

We obviously use the foundational elements from Nvidia, but we’ve been building the software stack in that space too.

JOHN: That’s fantastic. And I note that we mentioned earlier that you have this incredible 250 TOPS of performance, and we’ve talked with a number of other OEMs on the podcast about how sometimes it’s challenging for them to justify headroom in their capability. And I heard a number of podcasts from your CEO who talked really articulately about your philosophy of wanting to make sure you can plan for the future and expand the capabilities. Tell us about that decision you made to bake in some headroom.

VIDYA: Absolutely. And I think in that particular space from Gen1 to Gen2, as I said, a lot of the changes were more for our cost, manufacturing ease and all of that. But in the ADAS space, it’s very clear we put in a lot of headroom. You know, we’re 10x the compute capability from the previous generation. We have more sensing, you know, our cameras are eight megapixels. So we really, from sensing to compute, we up-leveled our ADAS significantly. And we definitely put in headroom because I think the ADAS software journey has just started for us.
And there was really a long way…we find already that our teams are very capable of capturing all those TOPS. And, you know, with both our prior background in microprocessor designs, you know, that software will use up all the compute and the memory you provide. But we’re already seeing, you know, if you start using all of the next generation transformer-based models, all the sophisticated models, you know, you need those TOPS, and more, frankly, you know.

ADAS and autonomous driving

JOHN: And in autonomy, you know, ADAS and autonomy, depending on where you like to be on that perspective, the mindset is still evolving, the regulations are still evolving. And so I think you’re beginning– what I’ve heard is– you’re beginning with a modest level of, I mean, incredible capabilities. But you’re also leaving the future, as people’s appetite increases and regulation increases, to do more and more.

VIDYA: That’s right. And I think, you know, what I would say is you’re exactly right. First of all, when people talk about autonomy… Our team is called “autonomy” but it really… it’s a continuum. It’s not a level four. You know, we don’t really go into that discussion. It’s really, I think all the way, you know, all of autonomy… That whole journey made possible all the safety features that are in vehicles today, like, you know, automatic emergency braking. So, you know, it’s really that whole umbrella of all the safety features as well as the self-driving capabilities. And what we did consciously is really keep headroom because the whole philosophy is improvements with OTA, enabling more features on OTA. And, you know, ADAS is far more sophisticated or autonomy or ADAS, because to actually add more and more features over time, there’s a complex AI loop which involves data gathering, training, and that takes time. And so we know we’re on that journey, but we know it takes time. And so it’s important to have the headroom for that exact reason.

Feedback for continuous improvement

JOHN: And one of the other things you talked about recently was the fact that you have a very tight feedback – you just mentioned feedback – loop. Being able to take driving experiences from your vehicles – anonymized, of course – take them to the cloud to learn, so that your vehicles can get smarter and you can see a situation… Ah, the vehicle handled it this way, but we should have handled it this way. And tomorrow and the next day and the next day the vehicle gets better.

VIDYA: That’s right.

JOHN: And that cycle of learning is important. We’ve talked about that at Sonatus, as we’ve shown in demonstration, how you can use our technology to do a similar thing. To be able to get feedback to the ADAS system saying, hey, there was this very strange situation. Why did that happen? Or can we capture situations like that to fix the problem in the future? I think it’s an important feedback loop you mentioned.

VIDYA: Absolutely. I think that that’s really key. And we actually do that everywhere, not just ADAS, right? We have some headroom in all our systems, and we’re always learning.

Over the Air Updates (OTA)

VIDYA: And really that’s another power of software defined vehicles, is the power of OTA, right? And we add features continually and expect to over the lifetime of the vehicle, and I start look forward too. It’s just like when you get your new feature on iOS, right?

JOHN: You mention, okay, it’s perfect because I was hoping we would talk about that a little. Your vehicles already today… You’ve done over 30 OTA updates since you launched your vehicles. Over 500 new features you’ve handed out to your customers. Of course, not to mention improvements in the way features already work. Tell us about your philosophy of OTA. We spoke about that the other day.

VIDYA: Right. And so for us, OTA is key, right? OTA is key because you know that– multiple reasons– you know that despite the best of efforts, bugs happen. And you don’t really want to have to go — And if you find out later on that you had some buggy software, or sometimes even buggy hardware which you can work around through software, but if you had buggy software — you don’t really want to have the customer bring their vehicle into service. It’s inconvenient for them. It’s actually a big overhead for us as manufacturers. So for us, OTAs is almost a requirement for every piece of hardware that sits in the vehicle that runs any software. That’s our philosophy. Very, very, very few… I mean, I would say that the exceptions are very minor. It has to be something really trivial and dumb that you don’t really care about.

JOHN: Yeah. You said you had a philosophy. It either has to be dumb or upgradable. Is that your philosophy?

VIDYA: Exactly.

JOHN: So a simple sensor, that it’s fine. We know what the sensor is going to do. Everything else should be upgradable over time.

VIDYA: That’s right, and it has to be really simple. Maybe a little light that has something we might be okay with, where it’s hard for it to go wrong.

JOHN: And so that fundamentally means you’re committed in a major way to being able to do OTAs across the vehicle.

VIDYA: Exactly.

JOHN: Because I think a lot of companies, when they talk about OTA, yeah, they’re going to give some new feature in the infotainment or something, you know, of course, ADAS perhaps. But most companies, I think, are not committed to pushing it throughout the vehicles to the same extent. You’re fully committed.

VIDYA: Absolutely. Fully committed. And we take that very seriously. And when we do part selection at the beginning, that’s a very key criteria. Obviously, the ECUs we develop in-house, you know, they’re really built for OTA. We design them. But even when we procure vendor parts, and we do have some vendor parts, we make sure that we have a clear handshake with them. And a plan for OTA. You know, down to requirements and bootloaders, you know security, safety, and all of that right. And like we said there are a multitude of reasons. One is to just be able to offer features down the road. The other one is to fix software bugs and the other one, and very rare, is really working around what may be a hardware issue.

Rivian R2

JOHN: We’ve touched on so many interesting topics so far. I wonder if you could finish by telling us a little bit about the new R2 model, which was announced recently. Everyone is very excited about it. It’s a little bit further out in time, 2026 first SOP. Tell us a little bit about R2.

VIDYA: That’s right. So R2 is part of what we call our mid-sized platform that actually includes R2 and R3. And we revealed both of them earlier this year. The R2 will launch first in 2026. So in terms of the electrical architecture, all the work we did in R1 Gen2 was sort of a precursor. It was very deliberate. It was not just done for R1 Gen2, but it was meant to be a platform that we’d pick up for R2. So, you know, all the work we did in establishing a zonal architecture will carry that forward. You know, not exactly the same ECUs, but modified ECUs. That concept of the zonal architecture will go forward into R2. We obviously will do, you know, a big refresh of the infotainment platform, because you expect by that time the demands of, you know, infotainment to go up. We have a few other tricks up our sleeve.

ADAS and autonomy… A lot of the focus, really, you know, the sensors, we did a huge upleveling of the sensors, you know, from like one megapixel cameras to eight. We think that’s actually pretty robust and will stay there. And by doing that, we can actually leverage all the data and the training we would have done from the R1 Gen2 platform and carry that forward into R2. So it really was very again, a very deliberate step we did earlier on. So that will have a long, stable platform on the sensor front.

And then a lot of the innovation, in terms of – not innovation, we will innovate everywhere – but the integration effort that we did, you know, going from 17 to 7 ECUs. On the low-voltage side, we’re going to be doing that actually on the high-voltage side. So we’re actually going to look at being more clever in terms of how we integrate our low-power electronics. So we’re continuously, you know, working on improving things.

JOHN: So from an engineering side, really sensible trade offs of, you know, R1 Gen1, R1 Gen2, evolution, and that same learning. And can transfer a lot of that to R2. But some nice, as you say, tricks up your sleeve and some great innovations.

VIDYA: And then really the focus on, you know, Gen2 for us is… Not Gen2, R2, it’s a lower price point. So obviously we’re looking at zonal architecture, acquiring all of that and saying, how do I achieve a lower price point, right, with that? And so there’s a lot of work in optimization around that. But we get to work on a more stable zonal platform at this point.

Conclusion

JOHN: Well, it’s very exciting times ahead from an engineering side and from a driver and a car-lover side. It’s exciting to see all the work you’re doing, and I’m so proud to see you as a friend of mine, and all the incredible contributions you’ve made to this great company into this great platform. So thank you for joining us.

VIDYA: Well, thank you for having me here. So it’s been a pleasure. And it’s remarkable. You know, when you leave companies you say you never know when our paths will cross. And I never expected to run into you with both of us doing similar things.

JOHN: With both of us being in vehicles, that’s right. Thank you so much.

VIDYA: Thank you. My pleasure.

JOHN: If you like what you’re seeing on The Garage, we hope you’ll like and subscribe to see more episodes like this. Thank you for joining us and we look forward to seeing you again very soon.