 All right. Good morning everybody. Welcome to Automotive Linux Summit. My name is Walt Minor and I'll be giving the presentation on an introduction to AGL architecture and roadmap. So who is this guy? So I've been a Linux Foundation employee now for eight years. I just uploaded all the slides to the schedule page so you can download all this. There's a lot of links in here you can use to go reference additional information. So I've been the AGL community manager for the last eight years. Used to work at Monavista and Mentor Graphics, did a lot of work with Continental, I worked at Continental and Motorola's automotive groups, as well as Motorola's mobile phone division. And most excitedly, my new recent endeavor is I am an apprentice sushi master, and I have a certificate to prove it. See? I know. I made sushi and it was delicious. So this talk is really intended to be kind of a brief intro into the AGL architecture and I've got a lot of links to other resources as we go through this for a general AGL introduction. There's another presentation on YouTube that I gave. It might have been here or it might have been at Open Source Summit Europe, I don't remember which one. And Jan Simon Muller and I, Jan Simon is right here. He's our AGL release manager. He we will be available for office hours at 4.20. They've organized a nice desk with oak desk with credenza and a corner office for me. It's really amazing. You'll love it. There's leather-bound books. No, that's true. We have an AGL sponsor booth. You can go see some of the, you can go see, we have three different demos that are running. And then tomorrow at 5.40, kind of the last session of the summit, we'll have an AGL developer, Birds of a Feather session. So you can come, ask questions, myself, Jan Simon, some of the other. Scott Murray is also a co-speaker with me. So any kind of questions you have about the current state of AGL development or how to write your own app or anything else, you can come ask us and we can make up an answer for you. So AGL Unified Code Base, that's what we call the distribution, we've had 14 major releases. And I think Dan showed a picture of all the fishes. We'll be announcing some new fishes at this presentation, so you guys will be the first ones to learn some of the new fish names that are coming up in 2023. We really have the goal of unifying the best open source software into a single code base and utilizing that for the entire industry. Our job is really, our goal is to really reduce fragmentation and focus on innovation and new features. And like Dan said, I think Dan said in his presentation, his keynote today, we're production ready. We're in Toyota and Subaru and other vehicles and coming to many more very soon. AGL has, we're out of the philosophy code first, upstream first. We've invested in automotive software components that are not available anywhere else. We are, I'll show you what some of those are in a few slides. We're continually evaluating open source technologies, open source projects as they evolve and finding best in class use case, best in class packages for automotive use cases. And I'm going to show some examples of how we've continued to evolve and evaluate what's out there. And then we've evolved the AGL UCB over the years. We also are pretty unique in a lot of the open source projects that the Linux Foundation runs is we invest in developers, we invest in contractors and developers to directly develop code for the AGL UCB. And we've also taken some of that investment and had our developers, our contractors work on open source projects like PipeWire to get automotive use cases into audio and Yachto and Lava and a host of others over the years. So talk about the transformation of AGL. So pre-Lucky Lamp Ray, pre-release 12, our initial releases included a lot of carryover and improvement of Tizen IVI packages. And what we found as we kind of moved along was that that wasn't, in some cases, wasn't serving us well. In some cases, we replaced some of the Tizen IVI packages, especially in automotive. We also augmented it. We also added, created an AGL compositor, which was all new, something we invested in based on Wayland. We added a web app manager that's based on the web OS open source engine from LG, as well as it's also based on Chromium. And so when we got to Lamp Ray, when we got to version 12, we had built up from Tizen. We still had some Tizen kind of components in there. We had the AGL app framework, which was based on Murphy and SMAC and things like that. And that was version 12. We released that in 2021. And we'll continue to do updates, 2020, rather, and we'll continue to do updates of Lamp Ray until 2024. What's happening in 2024 is we're using the Dunfell version of Yachta, which is version 3.1. And they put out a new patch release about every six weeks. And we quickly follow up about two to three weeks later with our own patch release based on the new Yachta version. But Lamp Ray is the final release version with that legacy AGL app framework based on Tizen. So if you have legacy, AGL applications will continue to support that release for another couple of years. So in, this is kind of the evolution of Lamp Ray over the last few years, you can see we are now up to 12.1.7. I think that's our ninth or 10th patch release of Lamp Ray. So this year, 2022, saw us transforming between Lamp Ray and Needlefish. We had another release, Marlin, in between. And Marlin is very much a transition release. We actually have End of Life that release already. But basically, we deprecated the old application framework. We deprecated SMAC and we moved to SD Linux. And we added a number of different images. We added Flutter to our app toolkit. So it's really a completely different beast that we have now. We've also transformed from using the vehicle signal manager that we had written and we were maintaining on our own to now using the open source version of Kooxa.Val and the VSS that is being developed jointly with Covisa. So Needlefish was initially released in August. And you can see we've already, this slide I think I missed one, but we've already made the 14.02 release. So you can see we've already started making some patch releases to Needlefish. And we'll continue to do that at least until March. This is just kind of an overview of our schedule for this year. You can see optimistic Octopus, the milestone one release, I think was just sent out. And we'll be starting the release cycle for Octopus. And I'll show that in our 2020 reschedule in a moment. So what have we done? Some more detail on what we've done in 2022 with Needlefish. Toyota developed a Flutter Embedder solution for AGL. So you may be familiar with Flutter and Dart basically developed by Google to create very nice looking, easy to develop UIs. But it was really based on, it was really for a mobile phone. So now we end for an Android solution. So Toyota has created an embedded version. There's a Metaflutter layer that we have for AGL created by Toyota and us. And that's now available in the Needlefish release. And we will have reference apps that you can see a preview of in our sponsor booth that are in our green machine. We have some reference apps that were developed not by Toyota, but by AGL developers. And we actually had some Google summer of code students who developed some apps. And so Joel Wunarski from Toyota will provide some really detailed information on the Flutter solution and how you can use, how you can make use of it and what the future is. And that'll be at 1.30 this afternoon. Silence this thing. Instrument cluster expert group. So they did, they've done a lot of work this year. They added DRM lease to the graphic solution to the UCB. They now have a reference solution with instrument cluster and our IVI in containers. And that is basically a preview of a version of that is available in our booth again next to our green machine. I believe you can see maybe a slight change, a slightly different version of that in the Renaissance booth. Curricouson of Renaissance will be giving a presentation on the details of what the IC expert group has been working on. And that will be today at 1.50 PM. So we had this legacy AGL app framework that was based on Tizen Murphy. And you can see in Lamprey we supported features such as app start and stop. We had the Linux smack for our Linux security module. We had sandbox, smack based sandboxing. We had packaging based on W3C widgets and we were using IPC as our standard web interface. As we move forward, we've already switched to using, we created something called app launch D which uses system D units for managing our applications. We're continuing to expand that coverage. We've switched to using SE Linux now. Sandboxing, well you should be adding actually, I think we have been not some ideas on what we'll do for the octopus and probably for octopus, definitely for pike release. Packaging, we're still working on a solution and we're moving to GRPC as our standard IPC interface. In the end, this gives us something that where we were maintaining most of this ourselves, there's not a lot of buy-in, smack isn't really being maintained by anybody. Our app framework was home brewed, there's a lot of maintenance to it. In the end, this gives us something that is much more future proof. We're using system D which is clearly kind of won the war in terms of how to do startup and how to do a lot of things in Linux. We do have SE Linux right now, it's only available in permissive mode and we of course are looking, you'll see a little bit later we're looking for help or donations in creating some rules for governing SE Linux. We, in terms of packaging and sandboxing, we studied Flatpak, in theory, it meets most of our requirements but it was only in theory. We found that extensive custom runtime support would be required for HGL. And again, with the idea that we're upstream first, that we are trying to maintain as little as possible that we can reuse from somewhere else without hard and fast requirements from our OEM members for what they wanna see in packaging, we really didn't see the benefit in spending a lot of money and a lot of developer time creating a Flatpak solution, runtime solution for HGL that we couldn't be guaranteed anybody would ever use. So we've deferred that for now. And basically we're working to enable some basic sandboxing using system D. That's kind of where we're at right now. I think that will again give us something that is easily maintainable, should do 80 to 90% of what we think people wanna do and should be fairly future-proof. And as system D adds new features, we can pick those features up too. So, IPC, standardizing our IPC, the GRPC and protobufs across the UCB, basically looking to replace all of our legacy web socket-based HGL service binders with GRPC. Basically gives us now a standard methodology to add new services. We're still in the process of converting some of our legacy services over to using GRPC and protobufs, but we've done most of the, we've done a lot of the major ones now. So I just talked about SC Linux, we're already running in permissive mode and we're looking for a developer to work on rules for non-permissive SC Linux or for one of our members to donate something that is already being used in production or at least some concepts that are already being used in production. The HGL compositor, so over the last few years we invested in creating a Weyland HGL compositor to replace the Kube compositor that was being used in the original versions of HGL. There's some information here and this blog entry from Collabra and Marius Vlad who did virtually all of this work. He has a presentation today at 3.30 p.m. And Marius will be talking about kind of the development of the compositor and use cases and how to make, how to best make use of the compositor. We made a significant, we were using originally, using, if we go way, way back, there was some use of the old Genivi audio manager, then we had created the 4A, the HGL advanced audio framework. Again, we wanted to stop maintaining something on our own. So we decided to look at pipe wire because that was in its early stages of being developed by the same people who developed Pulse Audio using the lessons learned from Pulse Audio and improving it on it with wire plumber, pipe wire and then wire plumber. So we made investments in collaborating with that community and driving the automotive use cases in there that we had identified over the years. And so you can see there's a couple of blog entries from Collabra who did that pipe wire work with us and with the pipe wire and wire plumber communities. So basically we have a really robust audio solution at this point and allows for a lot of configuration and policy management. So you can basically use it however you want in an automobile. We're using Jenkins and Lava to drive our CI. There's a presentation here from Jan Simon given in the past conference and then he'll be giving a presentation right after this, right here, stay tuned on speeding up builds and using some of the work that we enabled in Yachto and that we actually did in Yachto and pushed upstream to use PR serve and things like that and speeding up builds and making your developer, making life for the developers hopefully much easier and faster. So what are we doing next year? Our newest release will come out after CES 2023 February. Again, we'll continue to use Kirkstone, the latest Yachto project LTS. We'll have more app framework and GRPC work done. So more of our legacy service binders will be converted over to using GRPC and using App Launch D. Our, we'll have CES demo and basically we have the preview version using Flutter. You can see some of the WAM apps, some of the web application manager apps in the Igalia booth this week. Igalia has a sponsor showcase this week and they've done all the web app manager work and the Chromium updates and so they're showing a lot of their work. They've taken the legacy QT apps that we had and moved some of those over to HTML5 solution. We're also looking for donation of rules for SC Linux. I don't think this is going to happen in Octopus and the instrument cluster demo, the instrument cluster container solution becomes one step closer to production readiness. The other exciting thing is one of our GSOC students and you can see this in the booth. One of our GSOC students worked on a Flutter version of the instrument cluster and we're showing that on the green machine in the booth that we have this week. So there's actually a lot of, we probably have three or four different instrument cluster solutions that you can take advantage of in the AGL UCB, different images that you can take advantage of. So here's some exciting news. We have new fishes. So we have optimistic Octopus coming out in September, in February rather. Then we'll start development on our next release which will be release 16 or prickly pike and then boy, cues are really hard. Quirky quillback will be our 17th release that will come out in the beginning of 2024. You can see we have a lot of events that we're planning for next year between FOSDM and the embedded world again. We have some all member meetings, the embedded OSS summit. We also have, I don't know if I have it on here but we also have some face to face workshops that we do. We have some of those planned in between these times where we can have developers getting together and you can watch our mailing list or our Wiki page for announcements on those face to face workshops. So kind of a little more color to the Octopus schedule. We've got the milestone one is done, milestones two and three will come out. One before Christmas, one after CES and the final release just before we go to FOSDM. Then we'll have patch releases about every two months. That was the initial plan. The next year of 2023, Toyota will continue to add features to the Flutter and better. We don't have kind of an exact feature list right now. We're working with the IVI expert group on that. Exactly what they're gonna do next year in terms of Toyota's participation. But I think really one of the big benefits both the Toyota and AGL is the synergy that we get with the two different teams working together. I think at first there was some reluctance on the Toyota's part to engage with us heavily. Then as they saw that we were really making use and driving their solution pretty hard and we were actually asking for things that they hadn't thought about. We're now we have a weekly meeting with them. So instead of kind of being at arm's length, we talk to them every week. They're using our JIRA for issue management for the AGL specific issues. And we've got obviously our reference apps are not built by Toyota, they're developed by UCB developers. And so of course, as someone who's developed platforms for a lot of different companies, what you always learn is that your users do things in surprising ways. They always use your platform in ways that you don't expect, which inevitably breaks something, which I think has been beneficial and helps harden and provide stress case, stress tests and additional use cases for the Toyota developers. So I think there's been a lot of excellent synergy. We'll continue to add additional reference apps to the UCB next year and improve the ones that we have. So vehicle to cloud expert group, they've worked on, so last this year and then 2022, AWS has worked on a demo that they showed at CEA, I'm sorry, at Embedded World in June. They've continued to evolve that demo. They've got some vehicle to cloud using their AWS cloud services and they will show the latest and newest improved version of that at CES. I thought they were gonna be here this week, but they're not. They have identified a new lead at AWS. He's a former Stellantis employee who was a cloud architect there. They are committing to creating a spec, a message schema and a reference implementation, both on the embedded side and the cloud side and using MQTT that will be open sourced using AGL. So James is trying to get this initial work done and ready for the March timeframe, so we can start. Basically he's looking for us to help him with air handling, he wants to do some FMEA analysis, things like that. He wants us kind of like the Toyota relationship to help stress test his work and put it to use. So that hopefully with the Pike release in July, this will all be in there and it will be somewhat stress tests and then with the cool back release in September or in 2024, AWS will then turn that around, put that into their demo and we'll have a robust solution. So again, anybody is welcome to participate this. There's a lot of interest around vehicle to cloud, tasks and things like that. I think somebody just stopped by and talked to me before I gave the presentation here, so. And then virtualization and containers. Missy Amesan gave a really great overview of virtualization in starting with mainframes at IBM all the way up to the present day. Jerry Zhao has been our lead for the expert group for the last few years. He's here this week, he'll be giving a presentation today at 430 jointly with Hayden Peterswald from AWS on the service mesh and containers. Unfortunately Hayden has come down with something, he's pretty sick and he will not be here in person. He's at a hotel locally. We're trying to figure out exactly how he can participate. But, so we now have, you can see this demo of what Panasonic has done running in, again, in the AGL Showcase sponsor booth. There's a lot of exciting demos you can come see. You can see the work that they've already, Panasonic has already done in conjunction with the VertEG. That's kind of the culmination of work that was done with Panasonic, virtual open systems, open synergy and ARM and other companies. And this has really come together quite nicely. And this demo was running in the AGL sponsor booth. And then for next year, of course, we'll continue to harden this, continue to work on this in that additional use cases. The service mesh concept, we are talking with a lot of different interested parties like AWS and Sophie and people like that on what that looks like as we move forward. So, that's it for my slides. Basically, AGL, everything we do is open. We have an open mailing list, anybody can join. We have a weekly developer call every Tuesday that anybody can join, ask questions. You can see exactly what's going on. All these expert groups I talked about have calls at least every two weeks. IVI meets every week. So you can join those calls. We're also on IRC. Just don't ask us about any mechanical issues because we probably can't help you fix your transmission in your 1967 Dodge Dart. So again, all these slides, all these links are available on the schedule, the SCED page, I've uploaded them. And if anybody has any questions, I'll be happy to try to answer them. Yeah. Mm-hmm. So, I'll repeat the question for the, Jerry, do you want to come up and answer? Because you have to, if people are gonna hear you. So, Jerry can answer that question, but the, so the question was about VertIO and how VertIO, well, first of all, is VertIO up to the task in terms of performance and speed in the self-driving arena? And then the second part of the question was, what about, what do we see as the evolution of hardware and networking in the vehicle as we move forward and with VertIO? So I'm gonna ask Jerry Zhao from our team to take a crack at that one. Basically, okay. I'm the virtualization expert group leader and thank you for your question. It's a very good question. So first of all, I think as Walt and Dan explained in the previous presentation, so AGR is now focusing on the IVI or infotainment, this kind of a non-real-time operating features, but regarding this ADAS or AD is especially requiring the real-time and the function safety. So that is indeed a big challenges for the VertIO in terms of overhead. But on the other hand, actually the, some community like OACS or SOFY are already aware of these problems and start to discussion. So one popular solution, so maybe it's there, is that to invite the VertIO backend into the hardware. So that means from the software point of view, you will still have the VertIO interface, but you invited the VertIO backend into the hardware, do you have some kind of hardware assistance for the VertIO? So in that case, if you can reduce the overhead, although this is still undergoing and, yeah. This is very common. But keep the VertIO interface there. How far into the future do you see that, Jerry? I think maybe still three to five years to have a complete solution. But I think for some, for example, for NAT, VertIO NAT, I think Red Hat has already done a lot of work in that to realize that. But for some more complicated automotive devices like GPU or radio codec or something else, maybe I think we still need some time to do that. So it may be a hybrid solution at first with networking and other features built in. Yes. And graphics later coming later. Exactly. I know I know that, Yeah, I know that virtual, that was kind of the future, right? So I know that virtual open systems, no, not virtual open systems. Open Synergy and Panasonic have done some benchmarking on latency and performance of the AGL solution. And I guess I don't really have the data in front of me, but I think they will come up with a solution that holds up in terms of performance, especially with respect to latency in a VertIO. Especially as the hardware, we're using last generation hardware now to do this. As the next generation of hardware comes and there's more thought towards putting virtualization in there, I think the latency and the performance will vastly improve. Yes. Okay, I think we have a few more minutes. Any more questions? I'm not on the virtuals, are any online? No? Well, if there's no more questions, I am available to answer your questions about sushi making or anything like that. And stop by today, stop by our booth at the sponsor showcase or stop by the office hours. And if you think of any questions, we can talk there. Thank you, everybody.