 Good afternoon. Good evening, everyone. Welcome to the last session of Automotive Linux Summit. This is the one you've all been waiting for, the AGL developer, Birds of a Feather session. Quack, quack, quack. Okay. So who is this guy? Hope maybe you already know me, but I've been the Linux Foundation Community and Development Manager since 2014. That's me when I rode my motorcycle from Chicago to San Diego for Open Source Summit North America. And also recently, I have achieved Junior Sushi Chef Certification. And I have an official, I have a certificate. Okay. And then there's another guy who's doing this. Scott, don't worry about him. He's right here. Let's segue here. So Scott Murray, I work for a Invented Linux Consulting Company called Consolco Group. We've had a contract for many years now to help with AGL. I'm a developer that's sort of responsible for a variety of things in AGL. You might have seen me doing connectivity stuff recently with Cookset.File and VSS and VIS and things like the networking and Bluetooth, all that stuff. Also help out with the Yachto maintenance. So like the sort of upgrade process to take us from Dunfeld to Kirkstone and, you know, sort of some ongoing stuff in that space. I do a lot of the CES demo integration. So it's been interesting this year because I'm out of practice basically. I haven't done it for two and a half years. So we were, you know, picking up the pieces this year and moving forward to CES in a couple of weeks. And, you know, Walt's been generous and said much, much more. So I am kind of a jack of all trades. If you jump on most of the expert group calls, I'm on them the same way that Walt and Yen Simone are. So if you have a generic question about AGL, you know, I'm also one of the people that can probably help you. And Scott is not a budding sushi chef. They invited me, but I didn't go. He refused to become a sushi chef. So look for that on LinkedIn. So just a couple of slides of introduction. Some of these, if you were at my session the other day, will be familiar. Basically, really quickly, we had, you know, we've got all of our releases are named after fishes. Lamprey release 12 is our first kind of LTS version. We're now tracking along with the Yachto LTS. Dunfell releases. And we'll continue to update every two months or so as Dunfell releases come out at least until 2024, which is when they're scheduled to end. They extended it. It was originally two years. They extended it two years. Lamprey is also the final release with the legacy AGL app framework included. We removed, we deprecated all that after Lamprey. And now in Needlefish, we have basically replaced the previous, the old AGL app, reference apps and service binders and bindings with something new. We replaced the vehicle signal manager that was really heavily intertwined with the old, the old app framework. And now we've replaced that with Cuxa.Val, which uses the vehicle, VSS from Covisa. We're now tracking the new Yachto LTS, which is Dunfell. Kirkstone. Sorry. And we're now using system D units for app management. That's really the quick overview of where we are. And then I just wanted to show a couple slides in 23. So we're going to do Optimistic Octopus after CES. Basically, that should include all of our CES reference app updates and service updates. And whatever the latest Yachto is on Dunfell, on Kirkstone. And then so this is the schedule for the rest of the year. I know people get excited to learn what the new fish are. So the new fish are going to be prickly pike after Optimistic Octopus. And I'll bet you didn't know there was a fish that started with the letter Q, but there are some. And so we will have the quirky quillback coming in early 2024. So I'm going to put these slides up that you don't have to worry about basically a few more schedule slides, the schedules on the wiki page. And as usual, we have our weekly developer call on Tuesdays. Anybody is free to join. We're all on IRC. And we have our community mailing list. You can mail any questions or thoughts or whatever. You'll also get information, notice about releases and meeting updates and what not. All on that mailing list. So. And I'll point out the list.automotive.com. When you use the web interface like this, there's also a link to the calendar. Yes. That's the most up to date source of the calendar for meetings. Yeah. The calendar here is canonical, I guess, is the best way to put it. So with that, birds of a feather session, I'll open it up to any questions or great thoughts or anything else. Yeah. We have a mic here. Very quick question. Can you say a little more about how you're incorporating VSS? Step in since I've done all the work for it. So when we replaced or removed the old application framework, it had a couple of bindings with APIs for, you know, there's like a can interface and it had its, you know, it was derived from OpenXC, which forwarded release some stuff. And the issue that was partially that was there was no community revolved around OpenXC and all the XML can definitions with it. And we were the only people that I'm aware of that were really using it in open source. And it was really difficult for anybody jumping in to do can stuff in AGL that wanted to demo or experiment to use that because there's, you know, like we're the only people using it. And so that was one of the motivations when we did sort of remove the app framework that said, you know, instead of just taking that code and beating it into some new form to use it in the new, you know, post app framework world is maybe we rethink things. And it happened to me at the time I was looking around and I saw that, you know, Covisa had engaged W3C to start to standardize the VSS and VIS. So for maybe just high level a couple of minutes here, the VIS is Vehicle Information Service. So that's a server that exposes the data and VSS is Vehicle Signaling Specification if I have those right. And so it basically you think of it as a tree, a hierarchy of signal definitions. So you have vehicle cabin, you know, vehicle powertrain. And so you can build down and it's, you know, there is an open source project on GitHub where they basically have a metadata description that they generate the hierarchy of signals and they do regular releases. So in the last, I don't know, I guess a few months they've gone from VSS 2.0 to VSS 3.0, which is based on various community members submitting new signal things and going through the review process. So there's been changes like in 3.0 and it actually affected us a little bit was one example thing was they simplified the powertrain. It had some redundant levels of nesting and they sort of simplified. So that's the kind of community aspect of that. It's an open source project which meshes well with us in AGL. Like, you know, it started, you know, in Covisa, but now it's a bigger project. So that is the specification where we have this schema. Here's all the sort of signals. But then the VI asked the server to expose that. So to feed data in from sensors or, you know, can, for example, and actually have apps able to subscribe and do notifications, you need a server. So there is a reference implementation that's maintained, but it's almost a little less interesting to us. It's a big go sort of thing. It's very comprehensive and it is like, you know, it's a reference implementation. So it isn't quite as usable as what we did pick. So there's a project called Cooks.Val that Walt mentioned is another implementation of the IS specification. And so it's, you'll see Bosch are sort of the primary visible developers on that. There's a couple of different teams of Bosch contributing things to it. But there are other companies also contributing. When you go and look on the GitHub of it, there's, I think, Volkswagen and a few other, like Jaguar Land Rover and people like that. But, you know, we'll see a lot of development from Bosch. And we've spoken to the maintainer a couple of times. I join now the W3C calls for these things. And it's definitely, I would say, a good time for us to take it into AGL, because it's not just like a Kavusa project. It's a bigger thing that has a growing community. And we're able to demonstrate using it and integrating it into, you know, a product. And so at this point where I've, you know, done a couple of updates for now on a pretty recent version of Cookset.Val and AGL, and most like, I think pretty much all of our demo applications now have been converted to use it. And there's still work to be done there because the specification is WebSocket based, but Cookset.Val has gone a little bit beyond that and are using ProtoBuffers and GRPC, which is more interesting to us in AGL because it meshes better with a story of using, like, modern IPC in the vehicle. And ProtoBuffs by their nature are lend themselves to writing more robust code than WebSockets. And, you know, in these days, everybody's about writing, you know, solid, robust code. And the support for ProtoBuffs for things like Rust and Go and stuff is very good. And that's, I think, sees us into being able to have maybe down the road, maybe later in 2023 or maybe even in 2020 or start doing some more demos of things with, you know, these memory safe languages like Rust and, you know, work with some of the members. There are a number of companies that have started investing heavily and using things like Rust. And ProtoBuffs, I think, are a better story there because it's a first class citizen, you know, language for GRPC and ProtoBuffs. And it's, you know, much more secure by nature than WebSockets. So that's a bit of an evolution we will still continue on. And we'll keep enhancing the demos, wiring up more signals. There are a few things that I probably need to sit down and probably engage with the VSS folks a bit. There are signals that I think would probably be useful. So I have to actually find the time to actually maybe do a pull request or two against a spec and engage the community, which as anybody can do. So that's the beauty of it. Is anybody, you know, anybody who's interested in using this stuff, you can engage, you know, they have weekly calls, they have a mailing list and stuff as well. And it's, I think, I think it's going places and we'll see a lot more usage in the industry. So it's really become a big thing. And I think it's a good time, you know, we're maybe ahead of the curve actually, being able to demo using it. So I think that's great. So for whatever is worth in our project, we'll be collecting can traces and we'll, at least for the can traces we have DVCs, we'll convert them to VSS. And then potentially some of these traces might be used. Yeah, I mean, that's another application is that there are I think one of the demo feeder applications with Cuxa is essentially a replay tool. So you can feed just canned data in this one of the things that's what we're doing. But there's also a because they have a Python library to simplify using Cuxa from the client side. They also have that you can just record a set of signal updates and then play it back. So would be you would do that. But I think for new users, the VSS representation will be a lot easier to deal with. Yeah, yeah, it's the can signals are painful. Especially, I mean, I had to convert our stuff from open XC ish type of format that we were using with the old app framework to, you know, DVC. And there's some really interesting like bit position numbering stuff with DVC that, I mean, it wasn't entirely obvious in our old stuff, but it took me a few tries to get some of the signals right in with the DVC. So yeah, it's a little easier with just signal definitions. Quick question. So say I'm writing a survey, well, it's in the context of the removal of the application framework. If I'm writing a service that needs to expose capabilities to multiple applications or parts of the system. Is there a standard or recommended way to do this now from the previous conversation? I would kind of guess gRPC. Yeah, I mean, all the new stuff we're, you know, that I'm building for to sort of get us back to where we were with respect to the demo I'm doing with gRPC. I mean, we have just started on that. But it would be highly preferred this way. But I mean, we will take contributions if people are willing to maintain them. But it is, to some degree, there's some things that I think if we stay consistent and with, you know, things that are, you know, people intend to push as, you know, maybe demos or things that are appealing to people to pick up and use in production. There's some of the security stuff that we are, you know, at least hand wavy stages of how we would manage the credential stuff around gRPC. And I think if we can stay consistent and not have to worry about managing a bunch of different types of IPC mechanisms, then it'll be easier to make that, at least have a good story that is a starting point for people that want to pick it up. But ultimately, I guess people can do whatever they want. Oh, yeah, I mean, there is the Toyota based system code that's in Tree, which we don't use in the demo. It has all its own IPC mechanism. And there's a handful of libraries in there that leverage their IPC. But I mean, we're, you know, since we stepped back from the old app framework and we're trying to leverage as much open source that's out there, I mean, using things that are, you know, have big ecosystems like gRPC and have good stories around how do you secure these things, you know, and they're heavily used in the cloud, right? So we know that they're, you know, they're tested, right? So I think the best way to put it is we're moving from WebSockets being mandatory to gRPC and Protobufs being recommended. But you can bring in anything you want. But we're really intending to write everything in gRPC. Yeah, I mean, we want to demonstrate like what a future like forward looking product would be. Because in five years, it's much more likely that even if it's not gRPC, the vast majority of things are probably going to be something like Protobufs or, you know, maybe one of the things that have evolved out of that, like flat buffers or something. Because if you're going to sit down and write something today and start running a new project in Rust or something using WebSockets, which just JSON doesn't make a lot of sense in my opinion, like you're going to use something that has inherent typing and stuff to make it as robust as possible. And so that's we're hoping to get that into people's minds, right, like by doing this. Any other questions? As long as we can ask you questions back. Yeah. So it is, okay. Very simple question. So what kind of another, how to collaborate with a different foundation project? For example, today and for the future. For example, CIP has a super long time support kernel. So how to collaborate with one extension. Another viewpoint, PyTorch is a very good project, the newest. So it's a machine learning project for that. So how about how to collaborate for the automotive industry areas. It's just an example, sorry. So I mean, in general, in general, once our members or advisory board, I mean, they're all, of course, free to join. Since we're all Linux Foundation members, you're all free to join any of the subprojects. Our advisory board has approved and we funded joining Alisa and Yachto. I think those are the only two at this point. But certainly, if the membership wanted us to join other projects, we could do that. I think the biggest thing is that the members have to commit to participating. Right now, with Yachto, definitely, we have a lot of good participation between Jan Simon and Scott and Renaissance and other people. Alisa, I would say our participation started off pretty strong and now it's kind of weakened. Our member companies aren't really participating so much. So definitely, but if there was another project like CIP or MicroPython or any of those other ones that we wanted to join where we felt that there was clear synergy with the automotive industry, we would do that. So yeah. I can comment on the two examples if you want a little bit. Well, I mean, both of them have some technical challenges where you need to be investment. It's not like we could just take the super LTS kernel and easily integrate it per se, at least I think, because as far as I know, it's very specific hardware support in it. So it would be a thing we could probably have as an option, but we would like to see member companies either contribute that or specifically ask the advisory board for it. And the PyTorch, as far as I know, it's non-trivial to build that, right? There's people in the OpticFeeding that regularly mention it. To build that in a way that you have a reproducible build of PyTorch is a complicated thing. So us doing that, even having it available for members to pick up out of the AGL tree, it would be a maintenance effort. So it's another thing when we like, if members want that, they really need to get engaged, I think. It's not just going to be the handsome owner. I just do it on a whim. It's going to be something that requires some investment time. Yeah. Thank you. Anybody else have a question? So AGL, you've got like 100 odd members or something, right? About 150? Yeah. So what kind of proportion of contributors do you actually get from those member companies? Like a lot of them putting forward developers to help on the project or a lot of these people just kind of give you a point? A lot of members are consuming and not upstreaming code. Quite frankly, I used to show a chart. I probably have the data somewhere on how many individuals were participating in any given year. Let's say typically 50 contributors a year. 50 individuals a year contribute code to AGL. And that's from maybe 20 companies. So there's a lot of companies that are consuming. It's always interesting, especially at a larger trade show like CES or Embedded World. We'll walk around and we'll see companies are clearly using the AGL demo. I mean, there's our GUI, but they're not contributing anything back. Which is a problem with a lot of open source projects. It's one thing to be, it's like some dev board that's $50,000 or something that's fine. That's your project. But if it's something that, here it's on our dev board that we give out to our semiconductor customers, having that upstream in AGL is much better for everybody. But it's painful at times. You see this where some of these semiconductor companies are doing the work, but they don't contribute back. Generally in the automotive industry, there's the problem with the automotive OEMs and the tier ones don't know how to contribute back. And it's not that their individual developers don't know how. It's that their legal departments or their management doesn't allow them to because they don't understand the value and the benefit. And part of AGL's mission is, or part of my mission and Young Simon's mission, is to educate those companies as to what the value is to contributing back. So sometimes it's a legal battle. But some of our member companies have done a really good job of overcoming that. Panasonic, Toyota, Denso and a few others have really done a good job of figuring out how to how to contribute some of their code back to us. Anything else? Well, everybody enjoy ALS. Was it a good time? Everybody have a good time getting back together again after almost three years? I think we had fun. Don't forget there's the AGL face to face workshop tomorrow and Thursday if you're still in town and you want to join us we'll be in room 502 I think tomorrow. So before we wrap up one last call for questions. Thanks everybody and that's a wrap for ALS 2022.