 All right, our next speaker is Scott Murray. And he will talk about the Vehicle Signal Specification VSS and Cooksa.Val and what's the latest in AGL. All right, hello, everybody. After that introduction, I can probably skip the first slide. So very quickly, but myself, I've been using Linux for a long time. I've been doing embedded Linux since pretty much 20 plus years. I've worked at a consult group, which is an embedded Linux consulting company since 2014. And we've had a contract to work on AGL since 2016. And I've done pretty much everything all over the board in AGL, a lot of the octoproject upgrades and recipe construction and stuff, as well as a lot of the demo development and integration. So that's how I ended up doing a lot of vehicle signaling things in AGL. So very quickly moved through. I suspect in this audience, most people will not have heard of vehicle signal specification. It's a sort of up and coming specification for vehicle signals comes out of Covisa. And it's a big component of their SDV sort of working project, BMW, Volvo, Bosch, a bunch of different companies. And what caught our eye and my eye to some degree is that it's actually undergoing standardization with a W3C, which kind of blows it up. It's not just Covisa, it's an industry sort of level thing. And as well, there's an API spec that's related that's also sort of going through W3C standardization as well called VIS, Vehicle Information Service. And so these are specs. We need an implementation. AGL is a code first project. And so Bosch, for the most part, started this project called Covisa.Val, which is sort of under the auspices of Eclipse these days. And you do see that it's a lot of Bosch developers on it, but there's also contributions from other folks. And it's up on GitHub so anybody can contribute. So originally it implemented the VIS spec V1 and a little bit of the V2 in a C++ server that they were using Boost to implement. And then as things sort of moved through last year, there's an alternate implementation that the Bosch folks developed called the Covisa Data Broker, which is written in Rust. And it's sort of becoming their focus. They're gonna deprecate the C++ server. There's some convenient Python and Go client libraries and they have Python, what they call feeders that push data into the Covisa server. And so these are interesting things to us because it saves AGL from developing this type of stuff ourselves. And it's an up and coming sort of emerging standard. So because this is a lightning talk, we had all members meeting in Berlin a few months ago and a couple talks, one of the folks from Bosch, Sten gave a talk or the high level talk on VSS and Eclipse and Covisa. And I gave a more sort of detailed talk as well. So I just uploaded this to the schedule so you can grab it from there if you need it. Okay, so that's the very, you know, mild high view of VSS and Covisa. So last spring, we had just sort of pulled out our legacy application framework and wanted to have something for vehicle signaling and AGL. I sort of mentioned Covisa.Bal and we sort of picked it up and integrated it. So that was originally with the 0.21 release and vehicle signal specification 2.2. And you'll notice that as we went through the last year roughly, we've upgraded, you know, Covisa.Bal through a couple releases and the VSS is actually moving relatively quickly as more auto companies sort of jump on it and want more signals basically. So it's an open source project. You can go to GitHub and do a pull request and say, I think you're missing a signal for such and such and so there's a whole process. So we've been trying to keep up with that as well. So we're now on Covisa 0.3.1 and VSS 3.1.1. And so that sort of was our history of the last few releases. Octopus was a few months ago. We're working on the Prickly Pike release. It's hopefully gonna release at the end of the month. So we're sticking with Covisa.Bal 0.3.1 but I'm gonna bump us to a slightly post 0.3.1 commit level, mostly to pick up data broker changes. And we're gonna switch to the Covisa data broker as a default sort of VSS implementation. You know, basically it's future-proofing. The Bosch team are basically gonna focus on the Rust implementation because they think that's more realistic to productize which makes sense in the grand scheme of things. And it has this GRPC API which I sort of skipped over in one of the previous slides but that's very interesting to us because GRPC is a much more modern IPC mechanism than having to do all the string conversion and JSON with the WebSocket API. And especially if you're going to the trouble, let's build a memory safe Rust implementation. Protobufs and GRPC make way more sense. And so as a project in AGL, we're trying to push people in protobuf direction and this is sort of a furthering along about sort of process. So if you clone our latest tree rate today, you'll get the data broker is actually built into images but not all the apps are using it yet. I'm actively developing that to try and hit our milestone next week. So right now the QT app conversion is pretty much done in my work tree and should get pushed early next week. Our Flutter demo apps is gonna be a little more work there. Might not make the end of July but it should be and maybe the point release that comes shortly thereafter. And then future plans. We were following CooksetupVal pretty closely. I'm gonna continue doing that. There's so many features coming from the CooksetupVal team that are interesting. They just released VSS 4.0 and we know there'll be changes in our demo apps. Basically there was a big shift from left-right vehicle signaling terminology to driver-passenger, which basically, Marito, the industry folks are saying, then in our ECUs and stuff, we always use driver-passenger. So that's sort of a rationalization that's now in VSS 4.0. The DBC feeder for doing can input into Cookset basically. They basically have now started supporting actually doing output. So the can, the DBC feeder can subscribe to signals and there's some metadata to say when you see the signal send these can messages and so that just got merged and it might be sense for us to replace some pieces of our demo stack with that because right now we have a little demon that basically listens to HVAC signals and sends can messages. So if I don't have to maintain that and can point people at an existing upstream project that can do it, then that's probably good for AGL. And the last sort of new thing that I just learned of last week is they're basically developing a, basically a proxy. So the data broker doesn't implement pure VIS, the GRPC protocol is sort of its own thing. It looks very similar to VIS, but it's not a web socket, of course. And so there's this Cooks to VISS client that's just, it's often GitHub if you look for it. It's gonna migrate I think into Cooks about proper and it will basically be a proxy between the data broker and like the VIS web socket interface. So we'll probably fully convert to GRPC but I think it would be useful for us to actually have that you could build this proxy in AGL. So probably if you come along for our end of the year release you'll notice it'll be a recipe and we'll probably do something to exercise a little bit to show it off. So that's all I have, if anyone has any questions. See how I did for time there, right on time. Yeah, we have time for one question. Yeah, I'll be at the bar. If anyone that's really into vehicle signaling desires to talk about this stuff in exhaustive detail I'll be around. All right, perfect. Thank you, Scott. All right, thank you.