 So I lost my opening slide. I don't know how, but so my name, my introduction slide, my name is Walt Miner. I'm the community manager for AGL. All these slides, including the opening one, have already been uploaded to SCED. So if you want to take a look at the slides as we're going through them or if you want to see them later, feel free to download them. I've been the AGL development and community manager for almost nine years. It'll be nine years in August. It's the longest I've ever done anything. I'm a Linux Foundation employee. Prior to working for the LF, I worked for Monavista and for Mentor Graphics, embedded group, but then when I was there, I was working on automotive stuff. I worked for several tier ones, including Continental and Motorola telematics. I worked for mobile phone, did mobile phones with Motorola as well. And then if you go really far back, I did defense electronics, but I didn't want to mention that here. And that's a picture of me at Yosemite, when I rode my motorcycle from Chicago to San Diego and back for Open Source Summit North America a few years ago. And that's half dome. And no, I didn't climb half dome. I just took a picture of it. So AGL, so Dan just gave a little presentation on introducing AGL. I just wanted to start off by saying AGL represents kind of a lot of possibilities. You can do a lot of different things with the unified code base, as we call it. And just to give an example, or just to give some examples, these are some of the things that we showed at that CES booth earlier this year. We had those two green machines. I don't have a picture of it, but you saw a picture of it before. And Dan's presentation was Scott in front of it. And those green machines basically were running two different demos. One of them running our Flutter IVI reference implementation with a cute-based instrument cluster on a Raspberry Pi 4. So that had two different boards in it. The second green machine was running everything, instrument cluster and IVI on our single reference hardware that we showed before, using KVM, so running in a virtualized environment. We had the instrument cluster expert group. They had their own demo where they were showing their own instrument cluster. So we have multiple versions of the instrument cluster that you can download and you can run today. And then on the side, they had this little USB connected keypad and you could switch between the different version flavors of IVI demos that we have. You could see the Flutter IVI. You could see the cute or the web-based one just by switching and it would tear down the containers and leave the instrument cluster up and running like you'd expect it to be. We had Panasonic who brought a demo with running Verdi O with the open synergy hypervisor. We had Epam running a hypervisor, their Zen hypervisor, with HGL and Android and different virtual machines. So there are so many different things you can do with the UCB. You can build on top of the UCB. And this is just kind of an example of it. On Thursday night, we have the sponsor showcase and the tech showcase. So we brought one of those demos with us, thanks to Jan Simon and Scott. So we'll be showing that instrument cluster expert group demo with the multiple IVI systems and you can come over and you can play with it and you can ask us questions and we can make up answers and things like that. So come see us on Thursday night if you want to actually see this stuff in action and you can see a variety of different things that we have up and running that you can download today. So the last two or three years really has seen a lot of transformation within the UCB, within the unified code base. Dan talked about the fishes, our releases are named after fishes. Our upcoming, I'm going to show the schedule in a minute, we have the upcoming prickly pike release which just released its milestone one towards the final release. And as we've gone through the last few years, we've transitioned from using our legacy app framework, which was last supported in our lamprey release and we've transitioned away to using, from basically trying to maintain our own app framework and our own method for managing applications to using system D and some newer, you know, some more modern upstream technologies. We've, you know, in the past we only had cute reference apps. Well, we've supplemented that now with HTML5 based apps and with Flutter based apps as Toyota continues to develop their Flutter and better. We've replaced the old legacy vehicle signal manager that we had and low level can stuff, which was all very, very tied in with the legacy app framework. We're now using the Covisa project, Cuxa.Val, which was developed by Bosch and the vehicle signal specification. And now we've got Apple Launch D, which is using GRPC to basically manage and control the application launching. So we've made a, you can see as you go through here, I don't know why it's not showing up, but as you go through here, you can see the transformation as we've gone from lamprey in the first column to pike and we've basically moved from a lot of homegrown code that we decided that we had to build back in 2014 because there wasn't anything meeting our use cases, especially in the area of audio and the application framework and we've moved to more scalable upstream technologies that we're now combining and used by using Yachto. So just to talk about Yachto for a second and how we're using Yachto. So Yachto is a, I'm probably going to describe it wrong, but basically it's a set of tools you can use to build your own distribution. So we're using those tools and we're supporting, Yachto a few years ago declared their very first long-term support version, which was 3.1, their version 3.1 or the Dunfell branch. And we've been basically supporting, we've been doing releases on Dunfell based on Dunfell now for the last three years. We've made 13 or 14 releases based on Dunfell with on lamprey AGL basically they have announced they're going to continue with Dunfell through I believe April of next year and we'll continue to update lamprey, which has our legacy app framework and you can basically have all your legacy AGL applications running on lamprey and we'll continue to support that through, at least through the first quarter of next year as Dunfell continues to get updates. And you can see we just made a release 12.1.2 on June 9th. Then there's the current Yachto LTS is called Kirkstone, which is version 4.0. That's going day-announced. Yesterday there was a press release around this. They're going to support this until 2026, so they're going to extend that to a four-year life cycle. And we will continue to support Kirkstone releases then through that full four years. Our most recent releases, so after lamprey we've had Marlin, we've had Needlefish, now we have had Pike, have been on Kirkstone. We generally support the last release and then as we move into the next release. So anticipate that the new Yachto LTS becomes available next year in April, whatever version that is. Their naming scheme is beyond me, so I can't predict what the name will be. Anticipate that we'll switch to AGL 18.0 to the new Yachto LTS. I don't have a name for that one yet. R is kind of a hard name for fishes. I had a lot of research. I haven't picked an R name yet, and if I had I wouldn't tell you anyway. So anticipate that the R release will switch to the new Yachto LTS. And like we did with lamprey, we'll continue to support Quillback, which is coming out in January or February of next year. We'll continue to support Quillback with Kirkstone updates until Kirkstone goes end of life. So get used to the Quirky Quillback name. You'll be seeing it for a few years. So just to reinforce that, this is kind of the schedule for this year overall. You can see Optimistic Octopus, which is we're doing the current Kirkstone updates. We just missed a date here. We just pushed back 1503 because we had some issues with CI that we found in CI. So some issues in testing, rather. So we'll be releasing 1503 probably end of this week or early next week. Prickly Pike, so that's our upcoming 16.0 release. We did the milestone one release last week. Just, I think I've got a... We just did a little bit of replanning on the next couple of milestones because we're a little late with M1. Again, we found some issues with testing before we could release milestone one. We had some late-breaking features that came in. So we just did a little tiny bit of replanning that I'll show you in a second. And then Quirky Quillback, we'll start milestones at the end of this year. So this is just kind of hot off the presses today, June 23rd. We replanned the milestone two and milestone three. I only... The M2 and M3 got pushed back two weeks. And in the final release, we only pushed back one week. We think we can still hold to the end of July right now. So in terms of our roadmap, what we're working on, the AGL is governed by the advisory board. The advisory board has... Each of the advisory board members have delegated a member of the AGL steering committee. The steering committee then kind of controls or decides what the high-priority features are. We do have a little bit of money that we spend on developers. And basically the steering committee has a vote, determines what are the high-priority features for the year. And based on those features, we come up with this list of the top 10 or 11 areas that we're working on for AGL for the year. And we use this to somewhat decide how we're going to spend our development money, but also to kind of let people know what it is that we're working on. And you can see this year, the software-defined vehicle really showed up very strongly in our ratings. I'm going to show a little bit now in the next few slides about each of these topic areas. But basically our SDV Expert Group, which is newly formed by merging the existing virtualization Expert Group and container and service mesh Expert Groups, are really hard at work on these top three features. And we're spending a little bit of money to get some of this done, but we've got a lot of buy-in and a lot of commitment from members like Panasonic and AWS, Amazon, and then our instrument cluster members really to get this stuff done. We've got a lot of vehicle-to-cloud features that we're looking at. Again, Amazon, AWS is leading that effort, and then Flutter is being led by Toyota. Basically, I'll show you in a second, we've got champions for each of these efforts at the company level, and they're really participating by contributing developers to this work on a regular basis. Like I said, the major areas are SDV, hypervisor, container, which is being led by, you know, at the advisory board, steering committee level by Panasonic and AWS. Flutter and the Flutter and Better is being led by Toyota. Instrument cluster is being led by Suzuki, Aishin, Panasonic, Renaissance. Excuse me. We really need to do a better job of improving if you've tried to use AGL and you've just tried to download it and write an app. We really need to do a better job of onboarding new developers, getting them ready to write a new app. Toyota's been kind of leading that effort through the Flutter stuff, but we really need to improve that onboarding, not just for Flutter apps, but for cute and web apps as well. So I'll talk a little bit about that more in a second, but basically when we pivoted away from the AGL, the legacy AGL application framework, we also pivoted away from W3C widgets and having a clean way to build and deploy apps. It's now a little bit harder and we need to really make that simple for people to be able to go do. So these are our active expert groups. So all of these expert groups, from the system architecture team, IVI, instrument cluster, SDV, vehicle to cloud, we merged our app framework and connectivity expert groups and our continuous integration and test expert group. All these groups are very active. They meet every two weeks via Zoom. And basically if you want to participate, this is a really good way to participate. In addition to these expert groups that meet every two weeks, actually the IVI expert group meets every week. We also have a weekly developer call on Thursdays. Anybody can call in, ask a question, we'll make up an answer for you or we'll get you the right answer depending on the day. But if we can't find the answer for you right away, we'll make sure we log a gereticket, we'll make sure we get back to you. I think we do a pretty good job of welcoming people into the community and making sure that we help them and get them some real support there during those Thursday calls. I've got a little more information on how to join those Thursday calls at the end of this as well. So I just wanted to go through each of the expert groups and the system architecture team and really highlight the high level things that each of those teams is responsible for doing and how you can get to what they're doing, how you can find what they're doing, and how you can participate. So our system architecture team, like the name kind of implies, is really responsible for the overall AGL architecture. If there's any kind of debate between, you know, that requires some escalation between expert groups or if there's a question that comes up in the developer call that really needs kind of an overall system view, it gets referred to the system architecture team. And the major topic that they're really working on right now is RTOS usage within AGL. How do we interface to RTOS that may be in a hypervisor, maybe in a container, maybe on a remote processor, maybe in a different processor in the same sock. And we're trying to basically come up with some rules and some guidelines for standardizing around that and for then eventually creating the code, developing the code to go build that out. I might have another some more words about that in a few minutes. But here's the Confluence page. This is a very active project right now. This, like I said, the system architecture team meets about every two weeks. There's a lot of people writing use cases and requirements around this and for the different possibilities. In fact, I know there's a page for this. Our app framework and connectivity expert group, I mentioned Vehicle Signal Service, which is a project created by W3C and CUCSA, I mean in CoVisa. And CUCSA.Val is getting, which is an implementation of it done by Bosch, is getting a lot of traction. We have a lightning talk later today from Scott to talk about what's been going on there. Recently and for the Pike release that's coming up, we've added the CUCSA.Val data broker. CUCSA.Val has been available now the last few releases, but now we've added the data broker, which uses, which has a GRPC interface. In order to use that, we had to have basically the latest or pretty much the latest version of Rust. And since Kirkstone didn't support that very latest version of Rust, Scott went and developed a YAKTO mix and layer for Rust. And so now we've got that available, we've made that available to the whole YAKTO community. And so that's available in, that'll be available in the Pike release. App framework has a lot of projects going on. And like I mentioned before, we really need a solution for deployment of apps that eases our developer workflow. We have talked about it a lot. We haven't really figured out a really good solution. If that's something you're interested in helping with, we have a Confluence page that kind of describes the issues and the problems around that. We've looked at solutions like Flatpak and things like that. We haven't come up with something that really works for us yet. So this is again, I have some calls to action coming up later. So if you want to get involved, this is an area where we definitely could be looking for some help. Again, the app framework expert group has recently been spending a lot of time trying to standardize our HGL IPC to GRPC and using protobufs. With our legacy app framework, we had standardized around using WebSockets and signals and a signal solution. I'm going to get it all wrong if I try to think of it now. But basically, we're coming up with a standard, we're having a standardized methodology to add new services, particularly in those areas where there's not a standardized automotive service like HVAC or vehicle interface or tuners or things like that, where there's nothing standardized out there in open source. We're working with Cuxa.Val now and the Covisa guys on standardizing that and through a GRPC interface. This gets into a little bit more about the evolution of the app framework as we've worked from Lamp Ray to Pyke. I think I've already described most of this, but basically our IPC was WebSockets. Now we're moving towards GRPC. The packaging part is what I'm kind of describing with the developer workflow and deployment. We're using W3C widgets. Again, we're trying to figure out what the standard solution should be going forward. There's a bug in this read T. I don't know what that means. Basically, it's SC Linux for Pyke. The IVI Expert Group. This group meets every Thursday. We've got basically the Flutter Embedder that's been donated by Toyota. They're very actively working on it. I think with us, they haven't been developing apps. We've been developing apps on top of it. I think our collaboration between us working on apps and them developing the open source version of the Flutter Embedder has been very helpful for them and for us. Of course, we get a Flutter Embedder out of it and they get somebody who's using it as anybody who's developed a platform in any kind of a capacity knows. Your users always use your platform in ways that you never expect and they usually break things mostly because they're using it in ways that they think is quite logical and you never thought of. I think this feedback has helped Toyota mature their Flutter Embedder quite a bit since we've gone through the last year or two with this. The software-defined vehicle expert group, again very active, being led by Panasonic with a lot of participation from a lot of different companies, I think that Dan listed in his presentation. We've now got Vert.io available in the UCB for hypervisor use cases. We're working on non-hypervisor use cases. We made some of those available in Octopus and work is continuing in the second half of this year to add more services and more devices to the non-hypervisor use cases. We're developing a prototype for workload orchestration and deployment with AWS. We've got a unified HMI that's been donated by Panasonic. It's been donated recently. We just had the first push into Garrett that we're just starting to review. Basically, it's a virtual display design that allows multiple ECUs to write to the same display using Vert.io. It's a very exciting piece of software. Panasonic has been showing it in their demos of AGL now for a few years, and they finally have done the legwork that they need to do to open source that to us and to upstream that to us. It may or may not make it into Pyke. I'm guessing it will not because it's a very big update and we just received it. But look for it as a technology demonstrator maybe in one of the Pyke point releases coming up in the fall. There's again a link to the Confluence page for the SDV Expert Group. Vehicle to Cloud Expert Group is being run, is being led by AWS. In the early part of this year, they've been defining this reference implementation that we want to work on for messaging between connected vehicles in the cloud using MQTT and protocol buffers basically making use of the VSS and VIS from CoVisa and Bosch and really the main use case they'll want to start working on besides transfer of the data from the ECUs through the central point in the Central Telemanics Unit that's AGL based up to the cloud is vehicle identity, making sure that we've provisioned and can securely identify the vehicle. Again, there's a Confluence page. There's basically again another call for action. We really would like some participation from some of the OEMs and the tier ones that have done work in this area before. We definitely do not want to reinvent the wheel. We want to make sure that if there's something in the VSS spec that we can use that we are reusing it. If there's something we need to work with the VSS community to extend the specification, we'll do that. Scott's been very active in making sure that we've got that interface to Bosch and to the VSS community. I think this is a real good show of collaboration between the two companies. Again, Scott has a lightning talk later on about the work he's been doing. For a vehicle to cloud, again, there's a Confluence page. James Simon from AWS that created it and has been working on the implementation and the requirements. But we really do need some feedback and some input from other people, particularly OEMs and tier ones. Instrument cluster. Yamaguchi-san will provide a little update on the instrument cluster later today. Our pike release will have basically the CES 2023 equivalents. You can basically reproduce their demo using pike. And then, like I said before, we'll have that IVI container management demo that we'll show during the tech showcase on Thursday evening. Our continuous integration and test expert group, so they're in charge of basically the Jenkins and Lava servers. Basically, they keep the CI infrastructure up and running. Fujitsu has been very active in this group as well, mostly contributing updates to our automated test suite, both in terms of contributing tests themselves. They've contributed a lot of tests and contributing updates to the test framework. We've now made S-bomb available in our needlefish and later builds, so you can go look at our release notes. You can download the S-bomb for all of our releases. Yachto has done a lot of work on reproducible builds, and so the CI team has done a lot of work incorporating reproducible builds into AGL, and now we're in the process of adopting Yachto's self-test to determine how far along we are with reproducible builds. We think we've done a really good job. Yachto has some self-tests that you can run to prove that you've got reproducible builds, and we're in the process of adopting those, as well as I'm not a Yachto expert, so I'm going to mess up the description of this. They've got this check layer thing where you can make sure that your metal layer is conformant to their specifications, so we're in the process of adopting the Yachto check layer for conformance to their auto builder stuff. See, I told you I didn't mean too much about Yachto. So, now you've seen all this exciting stuff. You want to get involved? Yeah. How can you help? You're going to say, well, how can I help? That's a good question. So we have calls to action, so basically we're looking for input. We're looking for input both in terms of requirements, architecture, and really especially for code in our vehicle to cloud expert group. Our RTOS work, which is just getting started, but there's a lot of work around how do we interface to RTOS, how do we incorporate that into AGL and make it easy for someone to pick up an RTOS and just interface with AGL. SDV, a lot of topics, but especially container orchestration, developer workflow like I've talked about. You can join the app framework expert group. You can join the call. You can join the IVI expert group call. You can join the weekly developer call, which is on Thursdays. And we have a documentation site, docs.automotivelinux.org. A gentleman in Nebraska, a postdoc student, Vinod, has been doing a lot of work on improving our documentation, but of course documentation is something that always could use improvement. So even if you're just, I encourage anybody who's just downloading AGL for the first time and trying to use it and trying to use our documentation and says, what the heck is going on here? It's pretty easy to contribute to our documentation. We've actually got a video that Vinod created, step-by-step tutorial. There's also information on the doc site itself on how to contribute. So a lot of ways to get involved were really looking for people who are interested in AGL. And I think we're a pretty friendly group. We're a pretty helpful group. Not all open source projects have a reputation for that, but between our weekly developer call, which is on Thursdays, we're on IRC. Just don't ask us for any help with mechanical issues. We do have people occasionally pop in and want to know how to fix a clutch on a nine beetle. Don't ask anybody in this group. We've got a mailing list that's pretty active, and you can just, you know, you can email me or connect with me in a variety of different ways just to ask how to get involved. Kind of the last call to action. We've had the same reference design. If you see the look and the feel of the green machine. We've had that for probably six or seven years now. If you're interested in design and automotive design and you want to get involved and help us with a reference design, we're more than happy to talk to you. So we're looking to kind of freshen up the look and feel of AGL. And if anybody's interested in helping with that, I've had people express interest in doing stuff with QT, in doing stuff with Flutter, but I'm really interested in seeing what ideas are out there. And we really want to make, try to make something available for CES this year. So we want to get moving on pretty quickly. So you want to talk about this some more? Guess what? We have a lot of people here who know what they're talking about, who aren't me. I don't know what I'm talking about. So if you've been involved with anything in AGL, John Simon is here. Somehow, some way, we got Marius Vlad to travel. He's been working on the project for I don't know how many years. I never actually met the guy in person before this morning. So Marius is here, you can talk to Marius. We have a BOF session today at 4.40pm. Basically it'll be an open discussion. Bring your questions, bring your comments, bring your great thoughts. We'll be right here at 4.40pm. And then we have our all-member meeting in Tokyo. There's still time to register. We have a workshop where we're going to, again, talk about our issues. And I'm not talking about issues you talk about with your therapist, but issues with AGL and plenty of presentations. There's a really good, if you go look at the agenda, we've got a really good agenda of talks on a lot of these high priority projects. A lot of the folks that are working on these high priority projects couldn't travel this week. I really wanted to make this, as we developed the schedule for today, we wanted to make this an in-person event, not a virtual event. So we focused on people who could travel. But for the Tokyo AMM we're going to have a lot of people in-person, some virtual, but we're going to have a lot of discussion about these high priority projects and topics. So with that, that's it. That's the end of my presentation. If you have any questions, I'll be happy to listen to them and try to make up an answer. Or even better, come to the BOF at 440 and we'll have a better answer. Any questions? Hold on one second. We've got a mic. One question regarding the app launch which you mentioned for application startup and control. Is this system D or is this some additional... We're using system D, exactly. Okay, thanks. Scott is the guy who did a lot of the work on that. Any other questions? We definitely wanted to get away from we had our own homegrown app framework. We definitely wanted to get away from that and use more of system D and what was out there in the community and make it reusable and understandable to people. Any other questions? We've got a minute or two left. I hope you enjoyed this. I hope this was informative. If you have any questions let me know or please come back at 440 because we're going to have a great BOF session at 440. Thank you.