 Hi, my name is Dan Koshy. I'm the executive director for the Automotive Grade Linux Project at Linux Foundation. And today, we'll be talking about accelerating software defined vehicles through open source software and more specifically about how Automotive Grade Linux is addressing some of the current trends in the industry. So first, just a few words about myself. I'm Dan Koshy. I'm a Canadian, French-Canadian actually living in San Jose, California now for over 23 years because it's too cold in Canada. I still play hockey at my advanced age. And I was the former VP general manager of the Automotive Division at Montevista Software where we believe we were the first in the world to deliver a Linux-based system in an actual car. And I love wine. So I'm glad to be here in Spain because some of the best wines are here. OK, so with that out of the way, I sometimes start my talk by saying, how many times do we see this? This is the competition for software defined vehicles. It's basically our phones, right? Because not only do we see one phone with a sticky cup, we see two phones. Sometimes I've seen three phones, Lyft, Uber, all these things going on. And it's sad. And the reason it's sad is because this battery is a lot smaller than my car battery. And this screen is a lot smaller than my car screen. But yet we still do that. So you have to think to yourself, the car has a better screen. The car has a better battery. It should be better. And the reason it isn't is because the software sucks. Let's admit it, right? The software just plain sucks. And why does it suck? And how did we get here? And the reason it sucks is because there's too much fragmentation in the automotive industry. Now, some of this is getting fixed, finally. Some of this is getting fixed. But the history is that a car manufacturer would request, from a tier one, would request a box with a plug in the back, one for power, one for connectivity. And what was in the box, the manufacturer didn't really care. As long as they met the spec, he needs to have this button, he needs to have radio, he needs to have this. And so a couple of years go by, they're shipping this box in the car. And then the manufacturer asks for a new box with new specs. And the new box has completely different software because either it's from a different vendor or it's from the same vendor, but they've moved on from Microsoft to some proprietary thing. Who knows? So we've ended up with, even in the same car manufacturer, different operating systems. Some car manufacturers still have to support four or five different operating systems from the past through their tier one relationships. But the bottom line is this is why we ended up in this situation. There's been no standard platform. And this is why Automotive Grade Linux was created. Now we're not the only ones, of course there's Android out there and I'm gonna talk about that where we fit in terms of Android. But just at a high level, what is Automotive Grade Linux, or AGL for short? You guys are all Linux Foundation attendees. You probably know all of this, but we're a non-profit organization, open source, Linux based collab project, hosted at Linux Foundation and 100% focused on vehicle software. And I'm gonna talk about all the areas that we address. The goal of AGL has always been to build, like I said, a single software platform that everyone can use to eliminate or at least alleviate this fragmentation problem. And so we're not in the business of building a platform that you can download straight to the vehicle. What we're building is a platform that allows OEMs and their tier one partners and their tier two partners and all these companies a single platform that they can use as the starting point and then customize it. So we've always said we wanna be like 70 to 80% of the starting point of a production project. But then the manufacturer with their partners, they select their favorite navigation provider, their favorite Bluetooth connectivity provider that is certified to connect with iPhone and Android phones. They select their favorite providers, they add this to the AGL system and then they complete the system for a given piece of hardware. So we never intend at AGL to be downloadable straight to the car, because sometimes people think that. And then with this, what we're hoping is that we have standard kernels for a given piece of hardware. Standard services layers for things like Wi-Fi, Bluetooth, LTE stacks, things like that. And then a standard application API for things like navigation, which we have, voice recognition, which we have, radio, telephony, all these APIs are standard. And so then the manufacturer can really pick and choose their favorite app provider and just integrate with AGL. And the good news is because we have such large presence now in the industry, a lot of these apps have already been ported to AGL. So it alleviates a lot of the work. So if you want to Spotify in your vehicle, well, Spotify has already been ported to AGL. So chances are it's quite easy to do because it's probably one or two weeks work, to be honest. At AGL, we're strongly a code first organization. And the reason I mention this is because a lot of other organizations in the automotive industry are spec first, specification driven. And often is the case, they don't have any code at all. They just have specs. And then what happens is vendors write code and become compliant to the spec. So they end up having vendor A, vendor B, vendor C all having compliance. But if you look at the code, they're all different. So now we're back to step one. Different code, different code bases, different kernels, more fragmentation. So at AGL, we said, we're not gonna do that. We're not gonna have a spec and we're not gonna have a compliance program. Despite a lot of pressure from big tier one companies to do this because they want to build their own platform and be compliant to AGL. And we said, nope, we're not doing that. If you wanna be AGL, you gotta download AGL from our website. That's the starting point. That ensures that everyone's using the same code. And we still have that strong motto to this day. AGL, we started at first by supporting infotainment or IVI in vehicle infotainment. And that's because this was the biggest pain point for the automotive manufacturers. Trying to be competitive with the smartphone, infotainment is the first thing we worked on. But since then, in many years now, we've added instrument cluster, heads up display, telematics. And we're also working on functional safety and ADAS, which I'll talk about in some future slides here. But we're already addressing all of the first four functions. And we have been for, wow, probably seven years now, eight years was our first release. We have 10 manufacturers supporting the project. You can see here we have very strong support in Japan. We have Honda, Mazda, Mitsubishi Motors, Nissan, Suzuki, Toyota in Japan. We have Hyundai in South Korea, SAIC in China, and Mercedes and Volkswagen in Germany. So we have a pretty good distribution geographically. Notably missing is USA. We did have Ford for a while, but unfortunately they dropped out of AGL because they're, I think, adopting an Android strategy. But nonetheless, we have quite good support. And when we say Volkswagen group, we wanna mention that it includes all the Volkswagen logos, including the very expensive cars. And I know Bugatti's been working with AGL because I met them at Consumer Electronics Show and I asked if I could have a loaner car from them so that I could demonstrate AGL and make sure AGL is fully supported on the Bugatti. And they said, Dan, we only sell 43 cars a year in America and you're not getting one. So I didn't get one, unfortunately. We have over 150 members at AGL. I believe we're about the third or fourth largest project at Linux Foundation, both in terms of membership and membership dues and things like that. We have quite a nice diversity of companies. We have, of course, the automotive companies, the OEMs, the tier ones such as Denso Panasonic, Aishin, Harman, Continental, Bosch, pretty much all of the big ones. And then we have most of the semiconductor providers such as Renaissance, Intel, Qualcomm, and XP, TI, NVIDIA. So pretty good automotive membership, but lately we've been attracting a lot of small companies, companies with 50 people, 100 people doing very specific things like security. We have companies from Israel doing security work for automotive. We have, you know, and they're not traditional automotive companies, but they're like involved in the ecosystem and that's what we wanted to do from the very beginning at AGL is include all these smaller companies that wanna be part of this new connected car ecosystem. And I think we're succeeding at that quite nicely. And then I have one more slide marketing-wise and then I'll get on to the software. Two more slides actually. We first ship AGL in a 2018 Toyota Camry and since then virtually all Toyotas and Lexus run AGL. We also have most of the Subaru legacy and outback run AGL, some Mercedes-Benz Vans, and we're expecting several Japanese makers in the coming few years, if not sooner, and also some big logos that I showed before from Germany expecting to come out with AGL-based cars. Where we stand in the market, we're actually leading Android, which is nice. This is not a chart I produced. This is a chart that came from IHS Market, a big analyst firm. And you can see orange is AGL and then the light green is Android Automotive. And as of 2023, AGL is roughly at like 18, 19% and Android is at, I don't know, four, five. So not too bad. And the reason Linux is down, that's what they're calling generic Linux. It's because it's being replaced with AGL over time. And then the one at top, which is the gray, is actually what I call the Android fork that is mostly used in China, where you don't get any Google support, you don't get any Google apps, you don't get Google updates, you get none of that. It's basically you take Android, you fork it, and you go off with your open source code and build your own. Okay, let's talk about software now. So AGL, UCB. We named it UCB, it stands for Unified Codebase. And the reason we named it UCB was very deliberate is to kind of emphasize that we're trying to alleviate the problem of fragmentation. So it's very marketing related. We name our releases after Fish, in case you didn't know. This is a fun thing we do. Google named their releases after desserts and we said, we gotta find something cool. And Walt Minor, my colleague, he said, let's do Fish. And I'm like, Fish, okay. And I don't know if it, because we have so many Japanese members who's thinking sushi, but anyways. So Agile Albuquer was the very first release in 2016, all the way down to Magic Marlin and then I'll show you the latest releases in a minute. The point of this chart is not to show you a bunch of Fish. It's to show you that we have kind of a, we have, first of all, we're doing two releases a year every year since 2016 and we have kind of a TikTok model where the release that comes earlier in the year, meaning Q1, tends to be feature rich where we have new features that we demonstrate at Consumer Electronics Show. And then the release mid-year tends to be less feature rich and more focused on bug fixing and hardening and long-term support. And so what we recommend to companies that start projects is you should take the summer release or the summer fall. It's always around August, September-ish timeframe. Nifty Needlefish was released August last year and one of the most important things there is that we, well, a few of the important things is that we switched to Yachto long-term support release 4.0, Kirkstone is the name. So we tried to align with Yachto long-term support releases so that we get the LTS support from Yachto and then we pass that on to our BSPs and the rest of our software to the AGL stack, basically. This was the release where we started really moving to Flutter. So we're moving away from QT in terms of App Framework and moving to Flutter and I'll talk about Flutter specifically in a few slides. And this is also the release where we started supporting WebOS for OSC and Chromium. We've been supporting Vert.io for several years. In fact, the people doing the Vert.io work, if you're familiar with Vert.io virtualization, Vert.io is also what Android supports. We support the exact same Vert.io and the cool part is the people doing this work are from Panasonic. They're leading this effort and they are actually the one that have written the code for AGL as well. So now we have the exact same code for Android and AGL and why is that important? Well, at AGL we support more than just infotainment. We support instrument cluster and so if you have a Vert.io environment and a single processor, you can run AGL instrument cluster side by side with Android and that's very attractive for several automotive companies because many of them have chosen Android for whatever reason and in those cases you can still use AGL for instrument cluster because Google doesn't support that and so that's quite attractive for us because then we get to participate in those vehicles and it's attractive for the automotive manufacturer. Optimistic Octopus, which is difficult to pronounce, it was released in February of this year. This release we updated to the latest version of Kirkstone but also we added Flutter, Auto and Better and a new home screen, dashboard, new HVAC apps, et cetera. So a lot of updates based on, again, us adopting Flutter and we also did an IVI and instrument cluster demo using containers. So you're able to, you can run it in a virtualized environment with hypervisors either commercial hypervisors or open source hypervisors like KVM or you can run it straight with containers. So really all the deployment options are there and it's up to the manufacturer and their partners to decide what to do. We also added VertiO loopback support and a little while back we used to support SMAC for security and we moved to SC Linux and we enable SC Linux in the image but in permissive mode and then it is up to the manufacturer and their partners to decide what policy they want to apply. But SC Linux is fully supported in AGL now. The latest release is Prickly Pike was released very recently in August, August 10th actually. This is our 16th release. Some of the interesting work here is that we've added actually significantly updated support for KUXA. Now KUXA is a vehicle signaling standard was developed by Covesa and W3C I believe jointly and we're not sure but we believe we're one of the only hosts of actual code for KUXA in the world so that's pretty cool. So we have full support for that. We also added the, we actually updated the container demo that I mentioned before for our instrument cluster and IVI and we added DRM lease manager for the instrument cluster as well. You can find a lot more detail on the release notes on our website here. So AGL we've never stood still. When we started the project and our first release was 2016 as I showed you, there was a lot of things missing in the industry. For example, we had to write our own audio manager from scratch because in a car it's not like another device because if you have a phone call coming in and the navigation's trying to talk to you and there's an emergency situation with ADAS, you know the audio has to be layered properly with proper priorities and believe it or not sounds simple to implement but it's not. It's actually quite difficult because every car has their own requirements and so we had to write our own audio manager and we've dumped it now because now we use pipe wire and we have the ability to do that. So that's just one great example, yeah. That's just one great example where we've never stood still and we don't mind throwing stuff away that we've written if there's something better that comes along and this chart actually shows several examples, right? We started with App Toolkit, QT and now we're moving to Flutter and Web App Manager. We wrote our own audio manager, now we use pipe wire. We were using SMAC, we realized SMAC is kind of dying. Let's move to SC Linux, it has better support. We started with a IVI shell and now we have an AGL compositor. These are just examples that we're not standing still and we're always willing and open to adopt new things. So if there's something in your community or your project that you want us to adopt, we're super open to it. Just come, propose it, we have a system architecture team that will look at it and then the steering committee will make a decision and decide whether we should adopt it or not. But we're very open to those kinds of things. In terms of expert groups, these are the experts group we have today. In other communities, they're called work groups. We call them expert groups, but we don't want to scare people away. You don't have to be an expert. My colleague always says this. You don't have to be an expert to participate in an expert group. We want everyone to participate and it's open to anyone. Some of the ones that have been the most active in the past, application framework and security, connectivity, continuous integration and testing, these are all still active. Speech recognition has kind of died down now because we've completed actually Nuance and the Amazon Alexa team are the two companies that wrote the speech track APIs for us. So two of the biggest leaders in the industry wrote those and those are kind of finished. Virtualization is super active and vehicle to cloud is super active and container and service mesh is super active to the point where these two were working on very similar things. So we decided to merge them and redefine the name to software defined vehicles. And basically we've been announcing this for the past few weeks now. This is a new expert group led by Panasonic, Jerry Zhao of Panasonic is leading this effort. And in our very first meeting, we already had some really big companies participating such as Amazon AWS, Volkswagen, Arm, Virtual Opal System, et cetera, Harman as you can see. And this is a call for people in the community to participate. If you're interested in this, I think this is probably without exaggerating, probably the hottest expert group in terms of expectations and participation that we've had at AGL since our inception. A lot of companies are looking at the future of software for cars and they're saying things have to change. We have to change the way we deploy things in vehicles. We have to use containers. We have to be able to push updates not that are not entire images. We can push containerized updates. These kinds of things are the things that this group will be working on that combined with virtualization. And I think this is the future of automotive. These kinds of things will probably not be deployed in cars in the next year or two but we're talking five years out. This is the kind of thing that the industry needs in order to get out of this constant difficulty of deploying software for vehicles. And so we expect big things from this group and we hope to see a lot of participation from the community. I'm gonna talk about a few more key AGL developments. We build our own hardware at AGL. This is not well known. We don't do this to make money. Actually, we sell it at zero profit because we're a nonprofit. But we build our own hardware because it's very difficult to find reference hardware in the industry. You sometimes, most of the time, have to sign NDAs. You have to get your legal department to look at it. You have to then spend potentially several thousand dollars per board. So we decided to provide the community with hardware and so we already have these boards that we sell from, with the Renaissance SOC, it's the Renaissance ARCAR. And we have this sandwich architecture where the bottom board is the vehicle board. So you have all of the signaling, can bus, things like that. The middle board is the peripherals like audio and camera and visual. And then the top board is the SOC, the SOC processor. And the idea is that you can swap out the processor with a new processor board anytime and the software will be virtually unaffected. Of course, you need different software image to be downloaded but the overall API is everything, nothing changes. And so this is available for purchase here. We're planning to add Qualcomm SOC. That work is ongoing now in the near future. We hope to have that as well. Oh, I just wanna add one more thing. So there's actually one car company that I know of looking at this concept for actual deployment where if they have a problem with supply, like a supplier supplying a specific processor, they can quickly switch manufacturing by changing the sandwich to a new SOC and have almost little, very little effect on the actual software. And so there's a, I can't say who but there's a company looking at this for actual building cars and deployments which I thought was quite interesting. Another key development is AWS is helping us put AGL on the AWS Graviton which is a cloud-based ARM64 processor. This is great for developers to be able to develop and test from anywhere in the world, from home or from sitting right in this room. So this is yet another great option and we're really happy that AWS is helping us with that. This should be available very shortly. I don't know the latest status but I thought it was gonna be released this month so hopefully we get that done. I mentioned Flutter several times in this discussion. If you're not familiar with Flutter, it's an app and UI development toolkit. It's an alternative to QT if you will because QT is quite well known. It was originally developed by Google as an open source project and but it wasn't automotive specific and what Toyota did is they took that and applied several automotive specific features to it including different screen aspect ratios and things like that and they contributed all that code back to AGL and so we are the home of automotive Flutter if you will and we believe that this will become the de facto standard. We already know of one other big German car company that is looking at standardizing on Flutter. If that happens and Toyota is already standardizing on it it will become the de facto standard I believe. It's not up to me and it's not up to us but we're supporting it, we're part of this effort and we hope this happens. We think it's the future and so we're right in the middle of it. Vert.io is also the future. This is pretty clear because we support it, Android supports it. There's really at this point no other game in town for virtualization of IO and what's great about this is it allows AGL to run anywhere, natively or on a specific SOC or even in a cloud environment with no change and this is already being demonstrated, this already works, it's not pie-in-the-sky stuff and we hope that eventually car manufacturers will actually start using this in their deployments. I mentioned earlier functional safety so we're also working with another Linux foundation project called ELISA. ELISA is working on enabling Linux in safety application, that's what it stands for. Things like nuclear power plants, aviation, train control systems, things that require serious functional safety. ELISA is working on those things, we're leading the automotive work group within ELISA and so our hope is to bring our, our first attempt will be to bring our instrument cluster software release to functional safety ready status. And by ready what I mean is you can't get real functional safety certification on reference hardware, you need the final hardware, which is only available to the car manufacturer, we never see final hardware. And so, but we will do everything necessary such as the testing, the artifacts, the documentation needed, all these things with the goal that the manufacturer can take all that and that's hopefully like 70, 80% of what they need and then go get certified on the final hardware. And we have one leading OEM that is planning to do this for our instrument cluster. I wanna quickly just mention AGL events because this is a cool part of what we do at AGL. It's a great part of participating in our community. We had an all member meeting in Berlin recently. This is pretty funny because you may have seen in the news the Radisson hotel in Berlin had a giant aquarium that blew up. Yeah, we were supposed to have our all member meeting two weeks just before that happened. Like, sorry, two weeks, you know, our date was two weeks from that explosion. And so we had two weeks to find a new hotel and it's not easy by the way. And so that was pretty funny that our AMM was almost canceled because of an exploding aquarium. It's the fish, it's the fish, revenge of the fish. That's a good one, I didn't think about that. Anyway, so this was a very successful event and I'm glad we were able to pull it off. Every year we participate also in Embedded World and this is a great opportunity for our members to participate for free. They can participate in our booth, show a demo of their stuff running with AGL. So if your company is a member and you'd like to participate, you can contact me anytime. We're gonna be there next year again. This is a fantastic event for automotive in my opinion. We also had the very first ALS Europe this year. ALS, which stands for Automotive Linux Summit, normally is always in Japan, well now we have two. So we have one in Japan and one in Europe. And so we had the very first one in Prague in June and that was really well attended and it was part of what Linux Foundation calls Embedded Open Source Summit, which replaces the old Embedded Linux Conference. So Embedded Linux Conference no longer exists. It's been replaced with EOSS and we're planning to have another one next year and AGL will participate. We also recently had our all member meeting in Japan which was in July, that was super successful. And coming up next month we're gonna participate in the Automotive Software Expo in Yokohama and again our members can participate in our booth and show a demo of their stuff. So if you're interested in participating, you can contact me. And then our biggest event of the year is Automotive Linux Summit Japan. This will be at the Adiaki Convention Center December 5 and 6. Just to give you an idea, this event pre-COVID was attended by about 2,000 people. So very, very well attended event for automotive. And finally we're gonna participate in Consumer Electronics Show. AGL will have a quite large booth here next to Mercedes, next to Keriad, Hyundai, Hyundai Motors Qualcomm, right in the middle of the automotive stuff at CES. And again our members can participate in the booth. This is what it looked like one year where we had two vehicles showing AGL demos and then big companies like Entity Data, LG, Panasonic, et cetera showing demos of their stuff running AGL. And this is the front. And you can take a photo of this if you wish, but these are also the upcoming events. And we've already decided we're gonna have our AGL next All Member Meeting end of February, which will be in Tokyo. Probably the week of Feb 26. We're finalizing Hotel Now. And then we'll do the AMM summer in July and that'll be in Berlin again because we're getting really good attendance in Berlin. It's convenient for a lot of people. And so that's also gonna be in contract phase for July. And that's all I have for slides and I have time for questions. Yeah, yes. Yeah. Yeah, so we've had that. So the question was, does AGL support long-term support, LTS, and what's your strategy? So we've had that discussion many times inside AGL. And there's always been a debate. So some big companies want us to do long-term support. They want us to support something for 10 years. Other companies say, no, no, no, we want AGL to be an incubator of technology. We want you to focus on new stuff, incubating things, cutting edge, we'll worry about the long-term support. And you can see why because some of the tier ones make their money on the long-term support, right? Let's face it, it's a business. And so they don't want AGL to be that. They want AGL to be just incubating things that they can use. And so honestly, at AGL, our long-term support right now is that we support the Yachto long-term support, but then that's where it stops. We support our releases for up to a year and a half to two years. We do dot releases, things like that. But we don't do a 10-year release, not yet. But having said that, there's pressure to do it. And we may do it. And it depends on the steering committee. Yeah, yes. Does anybody want to know? Sure, yeah, that's absolutely true. That's a challenge for any long-term support, yeah. Yeah, so today it's mostly the large SOCs, very powerful multi-core processors. They're all ARM-based, pretty much. We do support an Intel board for reference, but I don't believe anyone's using that for production. So we don't support any kind of, I don't know, I would say small ECUs today, but it's certainly not out of the realm of possibility. But today we support, you know, renaissance, Qualcomm, NXP, TI, those SOCs. If someone wants us to support it, they should join AGL and tell us what you want. No, really, we're that open, right? If someone needs support, we will support any hardware. The only requirement is that it has to have a Yachto-based BSP, because that's what we pull from. And the other one is it has to be supported. So if it doesn't build and something breaks, whoever manufactures that chip needs to help us. They need to fix it within a day or two, or else it won't build. We don't have the manpower to go fixing a million bugs in BSPs, we just don't. It's partly, I think a big part of it is the car company's wanting something new and something more cutting edge. And the thought was that flutter, because Toyota is having great momentum, like you said, with it, and now we know of at least one large German company, maybe two, that might adopt it. There's just a lot of momentum behind it. That's the primary reason, yeah. And the tier ones too, by the way, not just OEMs. Several tier ones want us to use flutter, so that's why it happened. Yeah, I mean, we don't get involved in that as an open source project. So I don't want to comment on that, but I'm sure there's some car companies may have had licensing issues, yeah. Any other question? Oh, yeah, yeah. Yeah, actually, yes. I met with John Deere, and they said they were using AGL for all sorts of things, like the big combines to track tracking and things like that, and yeah. Coming? Yeah. Yeah, that's what I was told when I met with them. Yeah, not under NDA. So, any other, you had another question? Yeah. Well, I think it's all, let's face it, it's all commercially driven, right? So if Toyota, which we know uses AGL, they tell Spotify, we want you to port it, and then they have to, right? So that tends to be the first port tends to be a commercial reason behind it, but then once it's ported, I feel, this is what I've seen, those companies tend to maintain it because they have to maintain that one customer anyway, so then it's easy for others to adopt because they've already ported it, they already have it, then they maintain it for different. Well, that's what I've seen. Yeah, okay. Oh, wow, okay. I'd love to talk to you after and find out what companies. Okay, yes. So, of course, the code base is over 100 million lines of code, so we have a ton of licenses, right? There's not one license, but our incoming license, if you want to contribute new code, is Apache V2 for new code, yeah. No, we don't do anything special for GPL V3. We don't try to avoid it, we treat it like anything else. If it's a package we need, we use it, and if the manufacturer or whatever has an issue with that, that's their problem. It's up to them to find an alternative or work with their vendor to replace it, yeah. Yes, yeah, that's the plan, yeah. I can't say who, but I can say it's a big OEM, and they've been working on it for, wow, I want to say four years, and they have the funding to bring it to fruition, so it's not just a pie in the sky R&D project, they actually want to bring it to real production, yeah. Yeah, and that's AGL running natively without a hypervisor, so that means full functional safety, because today the way to get around functional safety, I know because I was the, like I said, the VPGM of Automotive Division in Montevista, and we did the Chevy Volt instrument cluster, and the way we did that is that we did an overlay with an RTOS underneath that was certified that does the overlay of the critical functions, and then Linux is used for all the fancy graphics and everything around it, and this overlay thing is how a lot of companies have used Linux in instrument cluster, but to use Linux natively without a hypervisor, without an RTOS, that's the goal of this instrument cluster expert group. Correct, yeah, exactly. Okay, well, sorry folks, we're out of time, but thank you very much for joining. Thanks. Thank you. Thank you.