 I think a lot of people with the great weather are probably sipping some cold beverages out there. I know that's what I would be doing, I think, but I really appreciate everyone joining here for this talk, Accelerating Software-Defined Vehicles Through Open Source Software. My name is Dan Koshy. I'm the Executive Director and General Manager of Automotive at Linux Foundation. And specifically, I'm the head of Automotive-Grade Linux. And a few words about me. I was the VPGM of Automotive at a company called Montevista, which some of you may have heard. We were the very first company in the world to put Linux in a vehicle, which was the Cadillac Q-System and the Chevy Volt. I was also the head of Mobile Linux at Montevista, which was the first, we were the first to put Linux in a mobile phone, which was the Motorola Razer flip phone, which is a super successful phone. And then Android came along and killed the rest of the industry. No, but jokes aside, that was a really fun time for Linux because it was the very early days of embedded Linux where people thought, you're going to put Linux in a what? In a device? That's impossible. And look at where we are today where we're deployed in literally hundreds of millions of devices worldwide. I'm a Canadian, but I live in San Jose because it's too cold in Canada, although I have to say the weather in Vancouver this week is pretty nice. Okay, so with that out of the way, I like to start by asking people, you know, why is it that we buy a vehicle, which is one of the most expensive purchases of our lives, and we buy a $20 sticky cup and we stick it in the windshield and we put our iPhone or our Android phone. Everybody does this. And the reason we do this is because let's face it, the software in the car sucks. Okay, it has sucked for many years. It has not kept up with the expectations of the consumer and the expectations that we have as mobile phone owners where apps are readily available, upgrades are easy. You know, these things are just starting to surface now in vehicles, but for many, many years you just didn't have that experience. And the reason we got in this predicament is because of fragmentation. So the industry was plagued with too many operating systems all across the board, operating systems for instrument cluster, some for infotainment, some for other features. And even within a single car company, you could have some cars using QNX, some cars using Linux, some cars using Microsoft, some cars using proprietary RTOS. And this fragmentation really hindered the innovation. And this is why the car companies have not been able to keep up with the mobile phone, with the mobile experience. And this is why Automotive Grade Linux was created. It's to alleviate this problem. So for those that are new, I'm going to introduce, you know, at a high level what Automotive Grade Linux is and then I'm going to dive into some of the features and things that we're working on these days and some of the exciting upcoming things that will be coming up in the next couple of years. So what is AGL? Well, we're a non-profit, as you would expect. We're an open source Linux-based collaborative project focused entirely on vehicle software. We're hosted at Linux Foundation. We happen to be, I don't know where we stand these days, but definitely at top five projects in terms of membership and revenue and things like that. In fact, we reached 100 members before CNCF did. I had a bet with Chris Anicek from CNCF and he owes me a bottle of scotch that he still hasn't paid me. But anyway, so AGL is quite a big project. And the goal of AGL is to build a single software platform for the whole industry to really eliminate this fragmentation. And so we like to characterize it as developing 70 to 80% of the starting point for a production project. Now we're never going to be like production quality where you download AGL directly into the car. That's not the goal of the project because that's, frankly, that's too heavy lifting. Instead, what we want to be is that all of the common bits like the kernel, the device drivers for a given piece of hardware are common to everyone. The middleware for telephony, Bluetooth, Wi-Fi stacks, LTE, all these necessary features should be shared and common to everyone. And then the APIs for things like speech recognition, navigation, radio, telephony, all of these APIs should be common to everyone. Then the manufacturer takes AGL with their tier one suppliers and they add their favorite map provider, their favorite speech recognition provider. And because AGL is so ubiquitous now, we've already integrated with all of the major speech providers, all of them actually. We've integrated with the major map providers. We've integrated with all of these telephony and other services. So that pre-integration work's already been done, so the heavy lifting is already done and really makes it much easier for a car company to adopt AGL and reduce that time to market and really eliminate that fragmentation by making a long-term investment in AGL and building their own platform based on AGL. So that's really the goal of the project. We're strongly a code first organization. The reason we believe very strongly in this is because the automotive industry is very specification heavy. So very specification heavy. So there's a tendency to produce documents and having companies be compliant to the document, right? So we wanted to avoid that because other organizations have tried this. Another organization called Geneva Alliance had a specification. And what happened is you had vendor A, vendor B, vendor C all claiming to be compliant to the spec. But when you look at the software stack, it's different kernel versions, different versions of packages. It's just not the same software stack. So we're back to square one, which is fragmentation. So at AGL, we said we're not doing that. There's no compliance program and there's no spec. Now it doesn't mean it's the Wild West. You know, we have documentation. We document things. We document APIs. But we don't want to have a compliance program where we end up having a supplier saying, hey, I'm compliant, use my software stack because then we'll end up back to square one, like I said, which is fragmentation where multiple platforms will exist all over the place. So for this reason, the only starting point for an AGL project is the AGL website. You download the latest stable version, start your project. You're guaranteed to have true AGL. So what I've been working on. So the very first thing we focused on was infotainment. So this is, you know, in the center console with your maps, your telephony, your radio. That's the first thing we focused on because that was the biggest pain point. We've been releasing software for that now since 2016. So that's very mature and I'll show you it's being used in production. Then we focused on instrument cluster. That is one of our most exciting projects right now. We have a couple of car companies that are actually planning to deploy within the next year an AGL based instrument cluster. And I can't mention who yet, but this is happening now. And this will be on the streets very soon. We also have heads up display and telematics. All of these share the same code base where telematics is the, I would say the most dumbed down. Meaning that, you know, we rip out all the graphics, the 3D, all of that stuff. And we're left with pretty much just the base OS with all of the radio stacks and the ability to communicate to the cloud for, you know, telematics type services. And then also we're working on functional safety. I'll talk about that in a slide a little bit later. And AGL is being used by several companies as the base of advanced driver assistance, ADAS type of applications as well. Overall, we have 11 car manufacturers supporting the project. Pretty good geography in terms of world coverage. We have Honda, Mazda, Mitsubishi, Nissan, Suzuki, Toyota in Japan. Pretty much all the major ones. We have Ford in the US, Hyundai in South Korea. We have Mercedes and Volkswagen in Germany and SAIC in China. If you count the cars from all these companies, it's about 50 to 60% of worldwide vehicles. And when we mentioned Volkswagen Group, it's actually the entire group. And we know that several of these are using AGL. And I met with Bugatti and I requested a car. They said, you know, give me a car and I'll test your software, make sure it works. And they said, heck no. They only sold 42 cars in America that year. And they said, you're not getting one then. I said, okay, that's too bad. What about a Lamborghini then? Anyways, I still don't have either one. So much for that. Overall, we have over 150 companies. We have all the car manufacturers that I mentioned. We have big tier one companies, Denso Panasonic, Aishin, Continental, Harmon, Bosch. Those are all, you know, the biggest tier ones in the world. They're all members. We also have most of the semiconductor providers to automotive industry. So Renesos, Qualcomm, NXP, TI, NVIDIA, ARM, Intel, et cetera. And then lately, because we've kind of tapped out the members that are automotive, pure automotive companies, we're now getting a lot of companies that are not pure automotive companies, but they want to participate in, you know, connected car in the cloud. And a good example is Adobe. Adobe is not joining to be put a PDF in your car. They're actually, they have an analytics business that tracks IoT endpoints and consumer data. And so that's why they're interested in being part of our ecosystem. So we're really attracting a wider ecosystem now of connected car companies. The very first car to ship with AGL was the 2018 Toyota Camry. And since then, virtually all Toyota and Lexus in the world run with AGL. All the Subaru, Neuro, have AGL. Mercedes-Benz Vans also, some Mazdas, several others are about to come out. You know, this project was started, like I said, 2016 is when we started the code. It takes about four years for car companies to go through a cycle. And some of them started about four or five years ago. So, you know, we're going to start seeing a lot of cars on the road in the next couple years. In terms of market share, AGL is the market leader in terms of supported OS. So that's the orange line. You can see we have quite a market lead over Android. This is not my chart. This is from a company called IHS Market. They track these things. And you can see Android Automotive is obviously climbing. Generic Linux, I call it Generic Linux because there are a lot of cars with Linux out there, but they're not AGL. That's going down over time because they're being replaced with AGL. All these companies are realizing, well, why not get on board with the actual automotive version of Linux? And then the gray one up there is actually a fork of Android mostly used in China with no Google support, no Google updates, no security updates, no Google services, no Google Maps. So it's really a fork. You take it, you copy it, you're on your own kind of thing. So that's the gray one. Anyways, overall, so we're kind of hanging in there quite well. And the projection is that, you know, the market will be eventually about 50-50, 50% AGL, 50% Android. That's kind of what the analysts are thinking, which I'm really happy with. Okay, let's switch to software and the stuff we're actually working on. Our software is called UCB. It stands for Unified Codebase. And we chose that name to send a message to the market that we're trying to eliminate this fragmentation I was talking about. We name our releases after Fish. Our community manager, Walt Minor, came up with this idea. Android was naming things after desserts. We said, well, we need something cool. And so we named them after Fish, Agile, Albuquer, like I mentioned earlier. January 2016 was our very first release, all the way to Lucky Lamprey. The point of this chart is not to show you some Fish. It's to actually explain to you that we do two releases per year. And we follow kind of a TikTok model, like if you're familiar with the Intel TikTok model. One is New Node, and the next one is less features, but more performance and things like that. So we follow a similar model where the first release of the year is Feature Rich, because we do a lot of demos at the Consumer Electronics Show in Las Vegas. So it's Feature Rich. And the second release in the year, kind of the summertime frame, is to be more hardening security fixes, bug fixes. And so our members know this, so they tend to take the summer release as a starting point for production projects. And the two latest releases are Nifty Needlefish, released in August. So that's the one that some companies are using for production. And then the next one that we just released is Optimistic Octopus. Now that's a mouthful, just released in February. All of this stuff is on our wiki. Everything is public. You can go, you can read the release notes, you can download the code. There's nothing private. Some parts of the website may require a Linux Foundation ID, which is just a fact. In terms of expert groups, the way AGL is structured is that we have a bottom-up approach, where we have expert groups, and they meet weekly, every two weeks, conference calls, Zoom, in-person across the world sometimes. And then above that we have a system architecture team that oversees the end-to-end architecture coding guidelines, things like that. And above that we have a steering committee. And the steering committee oversees the big decisions like what features are we going to work on, what are the priorities. And above that we have a board of directors, which meets every quarter and decides where the money's going to go and what we're going to spend on. So the expert groups really are empowered to make decisions in these areas. Now we work on stuff that is not covered by expert groups. So this is not all that AGL works on. There's other things we work on. We may not have an expert group for it, but there could be a few developers working on something. I think the most active ones at this point are the instrument cluster. That's a really active expert group. They're working on really cool stuff, and I'll talk about it a little bit later. Vehicle to cloud is really active and important. And then container and service mesh and virtualization, we actually recently merged into a new work group, or expert group called Software Defined Vehicles, SDV. So this is what the overall expert groups look like. As I mentioned, SDV is brand new right off the presses from last month. So let's talk about some of the software trends, or the vehicle software trends, and how AGL is addressing them. So one trend that you hear all the time is companies building their own OS, like CPU.OS, Mercedes-Benz.OS, Toyota OS. If you're a geek and a tech guy like me, that's not the right use of the word OS, in my opinion. I'm a computer engineer by trade. I've coded for many, many years, and I don't see this as an OS. What these people really mean when they talk about that is a service delivery platform. They're talking end-to-end from the vehicle to the cloud, services for the consumer, data tracking, where they go, this kind of stuff. That's what they mean by OS. It's an overloaded term, overused. What they're really using at the base of this is AGL, and or Linux, and or components of both. And this is what they're using. Mercedes is a big supporter of AGL, so is Volkswagen. They're using AGL as the basis for the in-vehicle portion, and then they partner with some of our big members like Amazon and so on for cloud-based services, and that's what they're calling the end-to-end OS. So AGL is at the center of these things. Another trend is that the SOCs, the SOC processors in the vehicles are becoming very powerful, right? Four core, eight core, little cores, big cores, lots of cores. They're very powerful processors, very powerful graphics, and what we're seeing is the attempt to consolidate a lot of the cockpit features onto a single processor. At AGL, we've been doing this for many years. I think our very first demonstration of this was 2017, where we showed AGL instrument cluster running side-by-side with AGL infotainment on the same processor in a virtualized environment. And you can do it with containers, you can do it with open source hypervisors, and you can do it with proprietary hypervisors, commercial ones, no problem. We've shown actually all three variants of this. And this is a trend that is definitely happening. We know of at least one, maybe two actual production projects that have started to do this and actually ship it in a real vehicle, where you're going to see the instrument cluster and the infotainment on one processor with two different screens. And that's really, really cool, and AGL is at the center of that. Another trend is the growing software complexity and scale. I don't know what our latest numbers are, but we're well over 100 million lines of code at AGL. It's extremely complex, a lot of bug fixes, a lot of security fixes, and managing all of this is new for the car companies, because they're not used to that kind of environment and they're learning, right? So we created the container and service mesh expert group, which is, as I mentioned, now renamed software-defined vehicles, with the goal to simplify the deployment of, I like to call it the cloudification of the vehicle, where we treat the software in the vehicle more like a server, so that we're able to put, using things like containers, push updates and push entire images to the vehicle. And really kind of employ what the IT world has done for years, employ those same concepts and those same engineers, so you don't need... Embedded engineers are really hard to find. In the industry, you know, they're a rare breed. And to find embedded engineers and to have this all-upgrade process based on embedded software is very difficult. So there's a whole trend, and some members at AGL, including Amazon, is leading this, actually. Amazon AWS is leading this effort for us. To treat it like a server and push updates the vehicle like a server. And so we'll see where this evolves, but this is ongoing, and they're working on this now in the new SDV expert group. And then this brings me to the final one, which is very much everything I just talked about, which is the lines are blurring between embedded IT and cloud, and we think we're, you know, it's the cloudification of the vehicle, as I mentioned, and we think we're really addressing this by having the vehicle to cloud expert group work very closely with the new SDV expert group and addressing these needs and these features, things like, you know, protocols for over the air, etc. So we're working on all of these things right now, and we're really seeing this blurring of embedded and cloud. Other key developments. At AGL, we actually build our own hardware. That may sound weird for an open source software project, but if you're in the automotive industry, you know that getting hardware boards are extremely difficult. You have to sign agreements with the vendor. You have to sign NDAs most of the time, and then you have to pay, you know, $1,000, $2,000 for a development board. So it's very time consuming, very expensive. So our community wanted to have another option. So what we did is we designed from scratch an actual automotive reference board. We call it the sandwich. The vehicle board has all the vehicle peripherals, things like cameras and, you know, side detection and things like that. Then there's a peripheral board that has audio and things like that, and then the control board which has the SOC. And the idea is that we can swap the SOC with a different one without affecting the software, meaning that the AGL image for that board will run perfectly fine. And to take it a step further, there's actually one car company that wants to do this in production. So they want to be able to use this sandwich approach where if they have a shortage of an SOC or a vendor problem or a cost problem, they can quickly switch to a new one in the same production line. That's pretty innovative because that's never been done before. And so this concept, this whole reference hardware team concept was started for this reason. And we think that that's a really cool, innovative thing that's going on. We currently have the Renaissance SOC support, and we're going to add Qualcomm very soon. I said Q1, we missed that deadline. I heard it's coming out soon. Another cool development is that we're adding more options to run and test AGL. So we're running AGL on AWS Graviton, which is a cloud-based, ARM64-based architecture. Amazon AWS has been helping us with this. They've ported AGL to this architecture. I heard this is just about to be released. I think they're ready to go. So stay tuned for that. It should be available probably by the end of this month. And what this does is it alleviates, again, alleviates the need for an engineer to have a physical piece of hardware. And especially post-COVID, a lot of us are working at home now. It's kind of almost permanent for many companies. This allows them to do a lot of their development, their testing, et cetera, using a cloud-based environment, and they can do it from home. So they don't need physical hardware. So this is a really cool development. Another really exciting thing is Flutter. So if you're not familiar with Flutter, it's an app and UI development toolkit. It's an alternative to QT for those that know what QT is. And it was developed by Google and completely open-sourced. And what Toyota did is they modified, they took it and modified it and added several automotive-type features. And then they re-contributed all that code back to AGL. So we're the home of that automotive Flutter right now. So we have, I think it was like a million lines of code contribution. And it's a great opportunity for AGL to be competitive with Android in terms of ease of application development. And we strongly believe, because of the people we talk to in the industry, that Flutter will become the de facto standard for automotive for app UI development. So, yeah. So we've already moved all of our apps from QT to Flutter. And any new apps that we're developing will be Flutter-based. In terms of virtualization, we're working very closely on Vert.io. This is being led personally by the CTO of Panasonic. And it so happens that Panasonic also did all the Vert.io work for Android. It's the same people. It's the same code base. Why this is so exciting is because it allows AGL to be run anywhere, cloud natively, or on a physical SOC, using Vert.io as the standard virtualization for I.O. And what's also nice about this, it opens up another opportunity for AGL because for companies that have chosen Android for whatever reason, which is fine, you can run AGL instrument cluster side-by-side with Android in a Vert.io environment. And that's really cool. We've already demonstrated that because I'm pretty sure Android or Google is not interested in instrument cluster because that's a completely different type of application. It's quite difficult. But we are, and we're working on it already. So this is our opportunity for us to be in the cockpit where Android is the infotainment. In terms of events, if you'd like to participate in our community and attend some of our events, we just had the AGL AMM Berlin. I'm just showing it because we had to deal with that giant aquarium explosion. I don't know if you guys read about that. That was the hotel we were going to be in and just two weeks before our event, three weeks, that giant aquarium blew up and we had to find a new venue. So that was fun. Anyway, so we pulled it off and we had that event in Berlin. We also attended Embedded World. So if you're there next year, come see us. We're going to have a booth there as well. We do this every year, this show. We're going to be at a new show called Embedded Open Source Summit, which is in June. This is brand new for Linux Foundation. China replaces the old Embedded Linux Con, ELC, and it brings together a lot of Embedded different sub-projects, Zephyr, us, you know, several others. So we're going to be there full day. We'll be Automotive Linux Summit Europe. We're calling it. And that'll be June 27th in Prague. And then we're going to have our all-member meeting in Tokyo, July 11 to 13. That'll be at the Hilton Tokyo Shinjuku. So you can join us for that if you're a member. And then finally, ALSOS Japan will be December 5 and 6 at the Adiaki Convention Center in Japan. And our biggest show of the year in terms of public exposure is the Consumer Electronics Show in Las Vegas. We're going to be there next to Mercedes, John Deere, a lot of automotive companies all around us. This is a cool event for us. And as a member, and I'm plugging it a little bit here, but if you're a member of AGL, it's also a very inexpensive way to participate in CES because this costs, you know, like a half million dollars. And you can participate for very little costs and have a kiosk and participate in our ecosystem and our booth. So that's my plug. So that's all I have. And I think we have time for questions. Yeah. Oh, thanks. Yeah, I mean, we have a CI and test expert group. I didn't have really much time to cover it today, but we have a complete expert group on that. And we have actually a full suite of automated testing that we run every single build. Yeah. Yeah, it's a big part of what we do. Yeah. Yeah. I don't know what the latest price is because there's been SOC shortages and prices have gone up. Check our Confluence page on the AGL Wiki, but it's not that expensive. It's like under 1,000. I think it was like 5,600 at one point. Yeah. Well, a big part is because one of our big champions is Toyota and they chose Flutter. And they kind of pushed their ecosystem of suppliers to support Flutter. So it's kind of become the de facto standard. Now, it may not yet be the de facto standard in Europe or Germany yet, but I know that they're also using it and looking at it. So it's not up to me, but it seems the industry, that's where they're going. And if one other big manufacturer in Europe jumps on board, Flutter will become the standard, I believe. That's my opinion. I don't know. That's a good question. That would be a good question for some of our community members. They might know that. I don't know that, unfortunately. So we actually, I think I have a slide on that, but I may have hidden it. Yeah, unfortunately I don't have that slide. But yeah, we're working closely with Elisa, which is another Linux Foundation project. And we are a member of Elisa and our community manager, Walt Minor, is actually kind of heading the automotive work group. So we're participating in all the meetings. I think there's a meeting in, I forget, in Berlin coming up in June, so we intend to participate in that as well. The goal is, so our biggest champion is Suzuki. They're using instrument cluster for their production and they want to bring this instrument cluster for AGL to functional safety certification and they're working with a big tier one to do it. And what they're going to do is once they're done with that, they're going to contribute everything back. All the artifacts, the testing, the documentation, they're going to contribute all of that back to AGL. Now, that doesn't mean AGL will be certified. We don't plan to do that, of course, because we're not running on the final hardware. We're always reference hardware. But we do plan to have everything ready as much as possible to make it as painless as possible for the manufacturer to, not as painful. Functional safety and pain is normally associated, but to make it as painless as possible for the manufacturer to go get certified, that's our goal. Oh, let me add also, so what people do today, like when I was with Montevista, we did the Chevy Volt instrument cluster and we didn't get certification for the Linux part. We did a graphical overlay and had a small RTOS. So their RTOS did all the functional safety critical things, which was certified. And Linux did all the graphics, fancy 3D, you know, and we just did a graphical overlay for the things that are critical. And that's how we got away with it. Well, got away with it. It's approved. It's an approved method of getting away with it. Any other questions? I drive a BMW M550 and it doesn't run AGL. But my next car may run AGL because I have a few in mind. That's a great question. That's a constant debate. We have members, big car companies, and I won't name them because we're on video, but that tell us they don't want us to do security because they're ultimately responsible and they have this whole back-end infrastructure people that take care of it. And they don't want us to spend time and effort reproducing what they have to do anyway. But then we have another set of members that says, no, no, no, you have to do some security, you know. So we're kind of in the middle. We don't do the full-blown production level type of, but we do, we're part of the advanced notifications of security, you know, all these things. We're plugged into those and we get patches and we patch things before the public knows. So we do some amount, but not the full thing. And it's a constant debate at AGL. How much security do we do? How much effort do we spend? How much money do we spend on this? But in the end, each manufacturer is responsible. And in the end, they have lawyers. And in the end, they don't want to be liable. So they have to do it anyway. No matter how much we do, they have to do it anyway. So that's the bottom line. Yeah, I may have to remove a few because I may not have the permission to show some logos, but yeah, yeah. Any other questions? Okay, last call. All right. Thanks.