 Good afternoon, everybody. My name is Walt Minor, and I'm the community manager for Automotive Grade Linux. And this is our Birds of a Feather session for software-defined vehicles. And of course, the first question you're all going to ask, this is going to be mostly an interactive session. I only have three slides. First question you're going to ask, that I always ask, what is a software-defined vehicle? And so I actually spoke at a software-defined vehicle conference about six weeks ago. And I've attended a lot of meetings where we have a software-defined vehicle expert group. And I still don't know what a software-defined vehicle is. I'm trying to figure it out. So I wrote down various definitions and ideas that I've heard. We're going to delight the customer with new post-delivery features. That sounded great. We're going to have faster, safer, more secure updates throughout the lifecycle of the vehicle. I think that starts pre-production through five years out, 10 years out. I bought the car 10 years ago, and you're still providing software updates to me. It's a high-compute platform. I need a high-compute platform. I need a lot of horsepower. And I need to build extra hardware, because car companies always like spending money. They're going to build an extra fast computer with extra memory in it that they're not going to use at delivery. And that high-compute platform with tons of memory and tons of data storage, because you're going to be delivering new features, and you can't even imagine what those features are. You're going to have the metaverse in your car. It's all going to be hardware agnostic, and it can be moved throughout the vehicle. That sounds super cool. And then there's a vehicle data collector controller that collects data, lots and lots of data. I think in Megan's talk today, she talked about 2.5 gigabytes per car per day times 400 million vehicles, and you're going to be sending data to the cloud, and you're going to control the vehicle from the cloud. My friends at AVL were going to be downloading, in real time, an application to control my speed because there's a crash ahead. These are all really cool things, but I still don't know what an SDV is. So then I stole a slide. This is stolen, and I'm even going to give credit to who I stole it from. I stole it from Woven, our friends at Toyota. What's an SDV? So an SDV has autonomous driving mode, cyber security, cloud integration, V2X connectivity, and a user experience. So that's a lot of stuff to focus on. Our SDV expert group at AGL has been focusing really on the enablers for all of this, really focusing on, I think, VertIO as the vehicle abstraction, or I'm sorry, the hardware abstraction so that you can move that functionality around within the vehicle. You can have that high compute platform. You can have that zonal control that people talk about. So I'm going to just close with this one slide. Jerry might have some other thoughts, but I think what we should talk about is what SDV is an open source. So there's a lot of people who are trying to write specs about open source, about SDVs, and we know all the groups. It's an alphabet soup of different organizations. But I'll tell you that AGL is the only open source project really already in position for building the software defined vehicle of the future. So we're built and tested using open source tools. We collaborate with a large number of open source projects, including some of the alphabet soups that I mentioned. We've got downloadable binaries today for Kimu and a wide variety of boards. And Jerry's group at Panasonic has demonstrated that they can run the same binary, the same executable on an ARM board, I'm not an ARM board, on a Renaissance board and a Qualcomm board and in the cloud. So we've already got some of these building blocks in place. We're the only projects that we're not captive to corporate sponsors. We're not interested in writing specs because there's nobody on AGL who wants to write a spec. Everybody wants to write code. We love writing code. And we're not one of those projects that have a lot of orphaned or bit-rotted code that sometimes companies just take code and throw it over the wall. And we've seen that in some other organizations. So if the code works, if it satisfies a need, we'll use it. And we really believe in collaborate and share. That's the only way we're going to increase velocity, reduce costs across the industry. And when there's an open source version, open source code version of a standard, everybody wins. We've seen throughout my life, so many specs that were written starting from, let's start with the AT command spec, that were just a nice little API or interface but nobody ever defined behavior. Nobody ever told you what was supposed to happen when you invoke that interface. Is it synchronous? Is it asynchronous? Do I, what's supposed to happen? So at the end of the day, the spec plus the code equals everybody wins. So I think what we should talk about is what part of the software defined vehicle should AGL continue to work on in the next couple of years that gets us closer to the vision of delighting the customer with a high compute platform that is always connected. So I'll open it up for, I'll start by opening it up to Jerry to see what his thoughts are. Jerry's like, what did you do to me? The topic of software defined vehicles. So let's first maybe think about what is the software defined products? I think everyone actually has some software defined products and anyone can have a guess. Oh, we did it very fast and anything else that our audience would like to give an example. Yes, this, right, right. And what's the common, what's the commonality of those products? Yes, that's all, right. So that is actually the software itself is defined the values of the product. So that means, so SDV, okay, it is vehicle but we can also see software defined value of the product. So this actually, you can think about about the updateability, now what's also the connectivity. So those are all basically actually enabled by software and all, and updates of software is more easy than the hardware. So that means that most of your values can be created by software continuously after the release and this content always make your product, if my product, I buy it and no software update then maybe in one year or two years, it's out of date. But for now, for this kind of smart devices, although there will be probably some performance issues if you're using for a long time, but at least for iPhone or for your smart watch, you can use the several years, right. So I think this may be one interpretation of the software defined of vehicles and also something probably also introduced in my previous speech yesterday. We can also integrate SDV to be a speedily deliver values. That means not only your software defined values, but from the manufacturer or say from the OEMs tier one and application vendor, what we need is to rapidly produce the values all enabled by this kind of technology. This is my comments. All right, anybody else have any great thoughts? I think we've got a microphone here. Oh, there's another microphone there. Yeah, go ahead. So I think if we compare it with mobile phones and cars, so in mobile phones, we mainly have software update, but in SDV, we might have software and hardware updates both because compared to mobiles, it's easy to update hardware in cars, I guess. So... Well, what do people do now? They upgrade their hardware. I bought an iPhone, I had an iPhone 8, and I upgraded my hardware. I bought an iPhone. It's like completely upgrading from one device to another. It's like in one car, we can upgrade some one piece of hardware. It might be another thing that might be in the SDV. To me, I think the barrier to entry that I've heard, in a lot of places is the thought that you're going, that somehow, and this is kind of a mindset change, I think, at the procurement departments of the OEMs, which is I need to have upgradeable hardware. So do I build that upgradeable hardware when I build the car? So I build a process, I put a processor in that's oversized for what I need today and more memory in than what I need today, but that comes at a cost. Or like you said, do I upgrade the hardware by at some point in the life cycle of the car pull this unit out and put a new unit in? I think that's a question that's kind of open. It's out there. The idea of, in the past, I don't know how much people do this anymore, but in the past, people would take their car and they would replace their radio and upgrade the radio, which the OEMs I don't think ever really approved of. But I think you're talking more about an OEM-approved upgrade path, where maybe you've owned the car for three years and now I can put a new compute module in there, right? We saw the other units, so that means we definitely need a clear interface, a common interface, a standard interface to make that hardware compatible with any future updates and the software running on the top of it. And I think this is also something, what AGL is also doing, this kind of interface definition in the RJC, our reference hardware expert group and also like our SDV expert group. On the other hand, beside this kind of mode, and I think for iPhone, I think in Japan there is a mode. I believe in US there's something similar that you mentioned that, for example, you have a continuous license or contract and we say some, some, some, some, I mean... You upgrade the periodic intervals. And every year when they release a new product, you can exchange your old iPhones, always the latest one, but you have this kind of a continuous program, a loyalty program, you can say. So this may be also a mode of how OEMs can sell automotives in the future. Buy a whole new car? Buy a whole new car? Yeah. I mean, you exchange a new model. Maybe not one year, but two years, every two years you can provide a upgrade the program for your user or customer. Maybe it's another software-defined product that we didn't mention was a PC. All right, my son wanted me to help him build a gaming PC, so we built a gaming PC. And then a few months later, he's like, well, Dad, I need more, I need a new graphics card. So what do you do? You go, you open up that whole thing, you swap out the graphics card, you swap it, you swap out a new one, but it's all based on common standards. And then, oh, and now that thing's sucking too much power, so I need a new power supply. And so is it that model, or is it the iPhone or phone, throw away the whole thing and replace it model? I think that's also something that will throw away the software. But you don't throw away the software. You don't throw away the software. I think in the automotive world, there is a trend of chiplets, which actually you have a more scalable, I mean, CPU, GPU, all this kind of computing resources and also the IO, I mean dice, so that you can customize the computing power and all this kind of device resources, so scalable to your own product. And since this kind of hardware architecture is also involved, I think this is also another aspect of its TV that in the future, probably it is called maybe something called software-defined hardware, so that is the hardware itself is supporting the software. Well, you've got another one back there. This is just my personal opinion, but yeah, I think updateability is definitely the key factor of the STV, but just decoupling software from hardware by virtualization or something is not sufficient, I guess. And what Azure should do first will be define the use case of the update in the vehicle. And how to guarantee that updateable software by design, I think. Test. Okay, so for me, STV is three key things. One is consolidation of multiple software functions on the same processor. And the reason for that is because there's just too many computers in a car. There's really, I think, some of them, of course, have to be separate, right? They do critical things, but a lot of them, instrument cluster, heads-up display, infotainment, easily should be all together. And so consolidation to me is definitely a part of STV. Number two is everything should be easily updateable, right? Today it's just not easily updateable. And after three, four years, your software base in your car is orphaned. And that should never happen, right? This should be supported for the life of the car. And so easily updateable is number two for me. And then number three is the software needs to support multiple generations of vehicles so that you're not throwing away the software each generation. And the analogy is very much like iOS and Apple, right? I mean, for people that own an iPhone, right? You download iOS, iOS supports multiple generations. Yeah, after a certain point, there's certain features that will not be supported on maybe your six, seven-year-old hardware. That's fine, but the car should be the same way. Maybe if your car is eight, nine years old, the new features are not supported because your hardware is too old, but the software base should be the exact same software base. And you're updating the software for multiple generations. And the car manufacturer doesn't need to manage which generation you're downloading it to. That's my opinion. Those are number one, two, and three for me. So can the car manufacturer or who, can the car manufacturer or somebody else monetize the post-delivery new features? So I got my car two years ago and now the new cool thing, the new cool piece of software has come out for the model year 24 cars. Who should pay for me getting that? Who pays for me to upgrade the software? Do I have to go pay $1,000 to go get these new features? What do people think about that? Is it something that the car manufacturers should just give away? Because it's not in their financial interests, right? I think the car manufacturers should learn from Apple because Apple monetizes via the hardware and they give away the software. And after a while, there's new features that you want, but you need to upgrade the actual hardware. You need to buy a new phone. So I think the same, this is my personal opinion. It should be the same for cars. The software should be free and the new features you're getting are free, but at one point, some of the whiz-bang new features require a new car. So maybe that's a reason for buying a new car. But then, so it's really like the Apple model, in my opinion, and that's what car manufacturers should do. I have a different opinion because I think for iPhone, it's still something affordable for me to exchange hardware, for example, every year. But for a car, I don't think so. So probably, I think instead of buying a new, a complete new car, maybe having this kind of additional services in my car, it will be something acceptable. Or on the other hand, maybe just, I don't need to own my own car just using the car rent, for example, that's also good enough. And for car rent, you can always have the ladies feature if Williams can support that. I think you're both right. And I think there can be some middle ground. So while the software and the features should be given away for free, in my personal opinion, if the hardware does not support it anymore, I don't see the reason to exchange the car. My hardware doesn't support it anymore, but my tires are still good, my steering wheel is still good. And we know phones that are easily fixable, easily exchangeable components. And there's no real reason to exchange the whole car. We only need to exchange, let's say, I need to upgrade this and that, easy you for that. And there should be a feasible concept from the manufacturers to exchange only those parts if needed for new features. So that would be, I think, give most benefit to the users and also to other points, like the considerations for the environment and so on, because it's not needed to exchange everything if your trust wants to run the software on your hardware, your driving seat is still good. I think in terms of what Dan said, for keeping the, in terms of keeping the software free, it's not really free, right? But if they're gonna give away the software, it's one of the hard problems, one of the difficulties that the OEMs face today in doing something like that is just the sheer number of SKUs they have for head units, for infotainment systems. Toyota probably has hundreds and hundreds of SKUs with different processors and different configurations for all of the IVI systems that they sell throughout the world. It's probably, I mean, having done this with Motorola and mobile phones, I mean, we would just have tons and tons of SKUs for the same phone that we were selling throughout the world with different regionalizations and different configurations. And now they've got not only that problem, but they've got Panasonic selling them head units and Bosch selling them head units and Conti and Alpine and everybody else and they're all different configurations. And I think a great way to move ahead and make that software free and easily ex-swappable between different versions is the hardware agnostic features of Verdi-O that we're already working on in AGL. The thing is that we, software is a very huge concept and it's a, you know, in my yesterday presentation the software volume of the vehicle itself is growing from about 6,000 times compared with what it is, what it was in 2000. Well, that means if every cost is a share, it's something that one OEM itself to take all the cost and give it free to the customers. No OEMs can suffer this kind of things. So that's the reason why open source is needed. At least maybe, for example, 70 or 80% of the software, those kind of non-differentiated software can be really developed together across the industry so that those parts can be not a burden to OEMs, tier ones or whatever and can give it free to the customers. And then for the remaining 20 or 30% for example, that is something OEM and tier ones or application vendors can have their differentiated area to sell it, that's my opinion. Alfred, it's about time you had something to say. I was waiting, we weren't gonna end this till you had something to say. Yes, Walt. So the question I have always in mind when we're discussing about SDV and next generation and so on is how do we ensure the maturity of the posts of the deliveries? Right, because nowadays it's super easy, right? So you have... Super easy, no one's ever described. I was not super easy, but easy compared to that what will come, right? Because we have ABC sample, we increase the maturity with the vehicle, right? We have winter tests, summer tests and so on. So here we find a lot of bugs and can fix it before SOP. But how will it be in future, right? So how it is ensured when I maybe I download a certain feature and then we get some performance issues or whatever can come, right? So how, who has an idea how to overcome this? This would be my, this is still not clear for me. All right, how do you ensure that you don't brick the car when you add some new lovely feature, right? Yeah, exactly, exactly. I just want to, I probably told you the story, but I just went through this experience with my Hyundai where they wanted me to update my own IVI system, format a USB drive and put it in and keep the car running for an hour and a half. And my concern through the whole thing was, well, what happens if I brick the car? You know, how do they know I pick the right version of the software off of their website? Because sometimes the whole system must be tested together, right? Right. And then everything gets more complicated, right? With hypervisor, with virtualization, metatology and things like that. So how, Matthew, to you. I give it to you. And maybe one thing, this, for example, the work that, Versio or Cloud, yeah, I don't know what was the name, that we test and validate everything on virtual environments in Cloud, yeah, all the software, we can test that. Something like what is running on, AGL can be tested on Cloud completely, yeah. Maybe that could be a solution. Yeah. So anybody else have any thoughts? I think on the hardware side, the car companies could learn from the telecom industry, which is switches, routers, are easily upgradeable, where you pull out a controller card, you put in a new one, which is double the power and double the performance, and that's very common. And then when new interfaces come up, when we went from gigabit ethernet to 10 gig ethernet, those interface cards were upgradeable to just plug it in. The car industry could really learn from that by having pluggable hardware that is easily upgradeable. You probably still need to do it at the dealer, but easily upgradeable for a modest cost, right? So you charge the owner, whatever, 500 bucks and they get a new control unit and they get all the new features and then you, and I don't know why we're not there, but that's something I would say if I was a car manufacturer, I'd be looking into that. And then you could even standardize that, call it the back lane, the interface, right? You could standardize it so you can have different hardware vendors compete for your business for the next upgrade, that kind of stuff. I mean, it doesn't have to be so rigid and not modifiable. Anybody else have anything? So just one closing question, and I'll ask if anybody has any ideas. What would you like to see AGL accomplish in the next year with respect to software-defined vehicles? I see Ishi-san. Ishi-san has deepened thought about that. The battery's falling asleep. Jerry, what would you like us to see AGL accomplish? For anything in STV, what would you like to see us have ready for the industry? Ultimate Go is something that we have a 70 or 80, 70% ready software for the automotive that OEMs and tier-runs do not need to do those, I mean, redundant work. Yep. I know model just wants better documentation. Better documentation. Well, unless there's any other thoughts, I think we'll wrap it up. This was really good. Say that again. Software architecture that can work for a long time and can be upgradable for a long time. Yep. And also from my perspective, I hope maybe it's not a software or this kind of thing, but from the AGL perspective, we should have more young man. Although from possibly we have already put a lot of young engineers into the committee activities, but especially for this STV and those kind of things, especially these future things, we need more diverse the voice, not limited to the one generation, but for different generations. I would say in a couple of years, my wish would be that AGL is the number one when we are talking about the open source and STV, right? Benchmark. This should be the goal because I can imagine in the next couple of years, there will be many initiatives coming out because open source, everybody talks about open source and STV, right? And here I think if AGL is the benchmark and is really ahead of the others, this would be my wish. Me too. I don't know if it is good or not. So Formula One cars has so many sensors and technologies and many things. So maybe we can learn many new things from them and we can make some of them as like normal for the day to day life, regular cars. So few things can be chosen from Formula One cars, for the normal cars, I guess, because they have so many sensors and technologies and they use softwares a lot. So I think so. All right, one last chance if you have a comment, question. This has been really great. Thank you everybody. And we have one last session left. Hope you enjoy it. Michelle is here to tell us about Verdi O some more and otherwise, I hope you enjoyed all the motivation summit. Thank you.