Diagnostics reimagined: How Eclipse OpenSOVD powers open collaboration and standard evolution

This talk focuses on the present and future of automotive diagnostics, particularly emphasizing service-oriented vehicle diagnostics (SOVD). The speakers, Tilo and Alex, introduce SOVD as a modern alternative to the older UDS (Unified Diagnostic Services) protocol, utilizing HTTP and RESTful interfaces for better performance and extensibility. They delve into the Open SOVD project, which aims to develop an open-source implementation of the SOVD standard outlined in ISO 17978. Key components discussed include the Classic Diagnostics Adapter, which facilitates communication between SOVD requests and UDS-based ECUs in vehicles. The speakers highlight the importance of community contributions in evolving the standard and discuss various tools under the Open ASAM ODX initiative, including DLT tracing and YAML formatting for ECU descriptions.

Thank you. Um, welcome everybody. Um, we are thrilled to uh, be here. Uh, thank you thank you for having us. Um, we are here today to talk about a little bit of uh, about diagnostics in the car. Um, how we shake this up a little bit. Um, think this a little bit newer. Um, I'm Tilo. Um, I'm I'm a product owner and software architect in STV matters

and working at the intersection um, with open source basically. And I'm a project lead for open SOVD and uh, yeah, and I have with me >> Sorry, I'm I'm Alex. I'm a senior software engineer also at Mercedes-Benz Tech Innovation. I'm doing the lion's share of my work in the open SOVD part mainly working on the classic diagnostics adapter. Um, what exactly that is you will learn if

you don't know in the next couple of minutes. Then take it away Tilo. >> Yeah, thanks. Um, yeah, so let's dig right in. So, just a short reminder reminder or a one on one on what is SOVD service oriented vehicle diagnostics actually. So, this is basically the newer version I would say of vehicle diagnostics interfacing. Um, um, you probably have heard if you had some exposure to

vehicle diagnostics about UDS unified diagnostics services. We will be talking about that a little bit too. Um, but um, SOVD is basically the newer or the the version that is more um, fitting into the STV era. because it's using more and more modern technology, right? UDS is basically based on bit manipulation and a very intricate protocol on the on the vehicle bus. And and SOUD is basically

HTTP and restful interfaces. It uses like known standards like HTTPS, which we also will see a little bit. And and has self-descriptive capabilities. And so it's much more modern. On the left side, you see a little bit of an kind of an architecture or how this is set up in a vehicle, right? You have externally, you have like these diagnostic testers that SOUD and some talk still

UDS. in the case of SOUD, they talk in the vehicle to something that we will call or would call the SOUD server. And which then calls diagnostic functions in the vehicle in applications that expose that functionality. Or if you have UDS-based or like old diagnostic protocol-based ECUs in your car, needs to somehow translate that SOUD request to UDS. And we have that CDA component, classic diagnostics adapter,

in the SOUD architecture that does that. We will talk mostly about that because this is what we as are contributing in SOUD and therefore know most about There's of course other components that get contributed to or need to be in that software stack and SOVD stack, which is also a big topic in the open SOVD project. So, what is actually that? So, the project Open SOVD is

basically the idea that we take the SOVD specification, which is laid out in ISO 17978, which is openly accessible to everyone, attempts to be an implementation of that, basically, right? And attempts to implement all these software components that are in that SOVD architecture that we just saw. Um and with that it tries to foster the standard because SOVD is a standard which is pretty new. Um and

we try to build some trust in the community and give the standard a chance of adoption in the end. And also on the other hand, we try to make it better by real world experience that we put into that we learn through um our implementation in that project and try to drive these learnings back to the standards, which we will talk a little bit later about then

we will try to build a bridge between SOVD and the old world of diagnostics. We will talk mostly about that today. And of course, we see this as a building block as a diagnostic subsystem that will be integrated in Eclipse S Core. and what I now want to show you is an Open SLP D what we have today in that project to a real world thing. Um,

so let's roll the video. All right, so what you have just seen is an application of what we have in Open SLP D mostly the classic diagnostics adapter to our GLC and we just re-flashed the light animation of this welcome um, animation from the Mercedes star to the Open SLP D logo. Um and that is done and and you can imagine that car is still built and

this light light ECU is still built using UDS. And so what we have to do is we have to bridge the world between good old UDS which is not to go away, right? That's will and this modern world um SOVD um that we want to have uh going forward. All right? And to do that, um um in the SOVD architecture, there is this building block called classic

diagnostics adapter, um which receives SOVD requests on one side and translates that into UDS protocol um and interaction with UDS-based ECUs in the car. So, we're building that, and while we're building that, um a couple of things that we keep in mind. Um one is extensibility, which um Alex will talk about um in a second. Um but on the other hand, it's very important that um we

have the Sorry, the reusability of code also in mind, and we do that yes, if you get um from modern clients outside the vehicle SOVD requests, that's nice, but there's also a world of UDS-based tests that still um right? Most of us in our garages and after sales have still UDS infrastructure. maybe you want to have provide in your vehicle SOVD infrastructure, but you have an UDS-based

client out there, and so you have to have a UDS to SOVD um adapter somehow. Um which is the other way around from this classic diagnostics adapter. And so, while we're building the classic diagnostics adapter and can talk already UDS and translate things from one to the other, the other way around shouldn't be so hard if we can't make sure that we reuse code, right? Um and

so that's what we aim to do there. Um also there's other other points and other areas where we have um reusable um components like um we have to understand ASAM ODX topology and stuff like that, um which is also and ASAM ODX data data types um that could possibly reused in ASAM ODX server component. And even projects beyond Open ASAM ODX. And with that, I guess I

give this over to Alex. >> Right, thank you, Thilo. So, let's take a look into how the community is actually building this. Although we at Mercedes-Benz are very interested in the classic diagnostics adapter for obvious reasons, uh otherwise we wouldn't spend time and money to develop that. It's not only Mercedes-Benz who is developing that. We're trying to build a community that is using Open ASAM ODX. So,

I've picked two Sorry, three totally random examples um were implemented not only by us, but with the help of our community. So, the first thing I want to talk about is DLT tracing adapter. So, um the Open ASAM ODX project is heavily building on Rust, and the uh tracing framework uh that is part of the Tokio project is the de facto standard when it comes to tracing

in an Rust project. So, um we wrote um a wrapper for the DLT library that is directly integrating into the tracing framework. So, in case you don't know, DLT is the de facto automotive standard when it comes to logging. DLT stands actually for diagnostic log and trace. And there's a very commonly known implementation by Covesa many companies are using. And we wrapped that library and the reason

for wrapping it instead of just re-implementing everything in in Rust is a lot of companies actually are extending um the lib DLT internally and we don't want to break that compatibility. So, by wrapping it to provide a way to safely interact um with that library but still maintaining compatibility to the existing workflows and the things that are running actually in the vehicle. yeah, so much for DLT.

One more thing you might think um well, that's logging is boring. Why are you even talking about that? And you're not the first guys to implement a wrapper around DLT. What's different with the Open Source VDDLT wrapper? Well, mainly two things. First of all, it's part of Open Source VDDLT so it doesn't rot in some side project that is maintained by someone in case they have any

free time left. No, it's really supported by Open Source VDDLT for shipping that um as part of Open Source VDDLT and that's the second reason you get support for that. In case you find a bug, you have an issue with that, you can open an issue on on GitHub and you will get replies and we will try to fix your issues. Um okay, I think I talked

enough about logging um another example. So, um as we already teased her in the previous slides, the automotive industry is using ODX to uh facilitate the ECU descriptions. So, in very very high-level terms, ODX describes which services exist on an ECU and how to talk to them, which services there are, which parameters they have, for example, which the service ideas. Um while ODX is here to stay,

um especially or at least for the foreseeable future, if you're not coming from inside the automotive world, it's a complex format. Um it requires tooling to create or to maintain it. Um so one of our contributors came up with the idea, why weren't we not using a format um developers are using all the time like well, YAML. And so they opened a a suggestion discussion in our

community, and they just started building it. So right now we have a prototype implementation where you can use YAML to describe your ECU. Um I'll show it later in the demo how it works exactly. So I won't go into further detail here, but that is a very cool approach, especially for prototyping or if you want to play around with simple ECUs or to create testing. Um yeah,

so let's skip to the next we are trying to No, we're not trying. We're making sure that Open ASAM is compliant to the to the ASAM standard. A great example for that is when we've implemented the fault endpoint in Open ASAM. So the fault endpoint means you can query which data trouble codes an ECU has. we implemented something that was compliant to our existing solution, but that

wasn't compliant to the ASAM standard. So one of our contributors uh during a code review mentioned that um well, I looked into to standard, there's a compliant way to save the to implement that. And although it broke our internal compatibility, uh so we have to implement something that we're getting our backwards compatibility back. We've made that breaking change and implemented something standard compliant, and that's something we

are really proud of that we are focusing on being compliant with standards and making something that is working for everyone and not only something that is working um internally at Mercedes-Benz. um what I'm trying to say is that Open Source V2D be useful for everyone. And the slide title, open source compound interest, what I mean by that, every contribution we get makes the product more valuable and

is further making it usable for another use case. Um so, it can add a new functionality. It can improve standard compatibility, but sometimes even a single suggestion or a single comment can change how our core functionality works. And yeah, let's dive into one of these stories. So, the power of community feedback. Um I already told you that we're um usually using ODX and YAML files, but that's

not the whole truth. Um both of these these file formats are text-based and they're complex to parse. They take a lot of lot of storage. So, we're actually not using that on the vehicle. Uh we're using a format called MDD, which stands for marvelous diagnostic data. It's a binary format, and the first version of that MDD format was built on a protobuf. spend a lot of time

into improving the the protobuf implementation, so its performance um it achieves our, uh, CPU time goals, our memory goals, the thing we're, uh, proud of about is it's maybe not the ideal ideal format to store things like that. So, eventually we ran into performance ceiling with that. We had some intermediate layer that made accessing the data in these MDD files a bit easier. So, basically it was

converting the data in the proto from the proto buff format into something more digestible or something we can query um, when we run requests. So, you can imagine an in case, uh, ASAM VD request is received on our restful interface, we somehow have to look up what that service means, how to translate that into a UDS service, and how to actually talk to an ECU to that.

And if we receive the UDS response back, we have to go all the way back, take a look into the MDD file again, and translate that back into, um, the ASAM VD reply. That means every request and every response has to take, um, or has to make lookups in the MDD file. Um, as you can imagine, there are quite a few requests when you're talking ASAM VD.

For example, if you're flashing an ECU, it's not like one request every 5 minutes, but it's request after request after request. So, it's very important that the MDD file is performant. So, um, while we had our intermediate layer, we ran into performance ceiling. We had some ideas how we can improve that, but that meant further caching, that also used more memory. We already had some caching in

place, for example, for strings, um, but when we published our benchmarks, we got simple feedback from, uh, community member, "Hey, have you tried flat buffers instead of proto buff?" The community member had experience with FlatBuffers for similar use cases and um while it's obviously not straightforward to replace your whole serialization layer, um based on the discussions with our community, we were very confident that this would improve

the classic diagnostics adapter uh substantially. So, we took the time, adjusted our application that is converting the ODX files into MDD files to spit out a FlatBuffers instead. We adjusted our CDA um to accept these files. And well, we ran our benchmarks again I'll show you the numbers. So, I'll I'll I'll give you a second to to parse that. as you can see, we got a bit

of improvement. we're using half as little memory, our is 76% faster, the peak CPU is 89% faster, and the response time, which means um from the ASAM VD request to the um UDS request and the response and back to um the HTTP response was 74% faster. So, that's quite substantially by only replacing the serialization Um the reason for these gains is a bit obvious if you take

a look into how Protobuf or FlatBuffers actually um work or how they differ. Um if you're serializing or if you're reading a message in FlatBuffers, um FlatBuffer works by just simple um offsets. And if you're accessing message in Protobuf, you have to parse huge chunks of the um of the MDD file and then have to build an object graph in memory that takes a lot of allocations.

and FlatBuffer just doesn't need that. by removing all that, we got these improvements and that's something that was built by the power of community and by working together. all of these things live in open ASAM OVD. But, if you're an OEM, you have your own implementations, your own um needs, your own requirements. So, open ASAM OVD is only useful for you if you can actually use it.

Um So, in open ASAM OVD, we've designed interfaces from the get-go, so you can actually extend it. So, we have a few and I'll show you in the demo in a second how these things actually work together and how they integrate into open ASAM OVD. Um I want to pick two examples uh here and first of that is the custom security. So, security is very, very OEM

specific. Every OEM has its own security, their own requirements, their own um way how to fetch um token or how to validate them. So, while we do have a very, very basic implementation of that plugin in open um that's something we say, "If you're BMW or if you're Mercedes, you want to implement that yourself because you want to keep your security plugin in your security infrastructure private

and don't want to open source it." And hey, if you want, we won't stop you. Um So, and the the other thing is um on the bottom right, we also support OEM specific features. That basically means you can add whatever you want into open ASAM OVD without even touching open ASAM OVD, without touching the open source part. Um you can add custom routes, for So, for our

demo, I built a custom security plugin that is using Google's OAuth uh authenticate against the CPUs. So, we're using cloud technology to authenticate against the vehicle. Um and that plugin was mainly built using um gigantic AI um and that shows you how simple that actually uh how that actually is. Um and it's using very little code. Um I showed you the thing later and you wonder, "Hey

Alex, that isn't little code." That's because I had way too much time and way too much fun by extending that plugin with all the recommendations Google Google has to actually validate these tokens. And it's almost production grade, but please don't use it without a security review. the OEM-specific features, what can they be used for? Let's imagine you have such a plugin that is using Google's OAuth to

authenticate your users against the the CDI, and you have a configuration file that is mapping an email address to role for a user, and you want to reload that configuration file at runtime. Um then you add a custom route for open SUV in open SUV that reloads that route or reloads that configuration file on the fly, so you can change access control at runtime. Um If you

think that's a good idea, I'm not sure if that's really something you want to run in production, but it's great for demonstration. let me take a look. Yeah, that's actually all I have prepared for slides. as you know, um you might have noticed I'm software engineer by heart. Um I'm very keen to talk about these things, but I also want to show you how that actually works.

So, I already said I prepared a Google OAuth authentication plugin. You're building well We I've built an ECU in YAML. Um I'm going to show you how it all works and how that is integrated into the CDA. But I'll spare you the rest of that slide. Well, I don't. Ah. That's better. Awesome. Okay. So that is a YAML file for our test ECU. Um it's a flux

compensator. So if you're keen with Back to the Future, you already know that what it is. But basically facilitates time travel. Um at the beginning we have some metadata that's boring. We have the ECU name. Um we have the protocols we support. Uh that ECU only supports UDS and DoIP. Uh IP addresses. And then we have the services. At the moment that ECU only supports read data

by identifier. And we can then define uh data identifiers for that ECU. So we have defined few identifiers. For example, we can read the name of the temporal technician so we know who did the last temporal displacement. and we can read the last temporal jump date so we know when the last time travel happened. Unfortunately, setting these things isn't implemented because we couldn't figure out in that

short time how to actually implement time travel. Um so we we focused ourselves on actually reading um important to point out here is that that service is restricted to a given audience. Uh so that means the after-sales cannot access that um temporal jump date info because it's a bit of sensitive information, so only um a user that has the development role can actually read that. For the

temporal technician um while it's maybe PII, we still allow the the after sales uh people to to read Um maybe keep that in mind that comes in later when we take a look into the implementation of the plugin. The rest is necessary, so the identification that it works with fairy ECU simulation. uh access patterns, we only have public read. That means it doesn't need any special authentication

aside the the roads we just discussed. And then we can define some data types like the technician name. It's an ASCII string with at most 255 characters. And the temporal jump date is a structure that has a couple of fields. And the rest of that file is boring. It defines do IP settings, UDS settings, the variance that ECU has. That's basically necessary so we can actually use

our ECU simulation to talk to that um flux compensator ECU. how to actually use that? Uh our current model is that you integrate OpenASOUD as a library. So, you still roll your own main function and integrate everything that is uh as a crate, so as a library in case you're not familiar with Rust. and then the main function is just setting a boiler boiler plate code, parsing

arguments. Well, you know, the boring stuff. Um eventually starts the web server. But, that is the interesting part. So, that sets up the the OF And eventually vehicle routes, but we want to take a look into the open Um it's loading a configuration file. I've teased it, but also boring. Uh that is the function to actually add the routes. You can see it's pretty simple. Um we

have two routes, one for the off callback and one for the uh rules. Um but let's take a quick look into how that plugin actually is implemented. that is the interface with the CDI. Uh let's scroll to the end. It's three lines of code, bunch of comments. and the interface is pretty simple. So the trade basically to defines two things. We have an off authentication plugin that

is running with every service call. Um that is basically checking these audiences we just took a look at. And we have the other plugin in um part that is doing the authorization. Um in case of all off that would be fetching the um the key. when we run that or when we convert that file into an actual MDD, we have this file. No. Turn presentation off. shoot.

Start screen mirroring. Huh? Thanks. Help, Tilo. >> You might want to turn off presentation mode. >> I mean, I can kill PowerPoint. Um >> Or that. >> We'll find our way back into PowerPoint. Uh sorry for that. So, if you take a look into um that little green tree, you all can't read at all. That doesn't matter. So, um that is just a little general interface that

you can use to browse the MDD files. A bit of a teaser, um we are actually using that and extending that with an MCP service, so you can eventually ask your AI about your MDD files. For example, a use case for that is which services are used for authentication, and the AI then spits out all the relevant services. So, um that's currently a personal project of mine,

but um we will make that part of Open Service Directory eventually. So, I have to hurry up a little bit. Um I have to see the AI running in the background. Um Not interesting how to start it. I'm just running a shell script to to start it. It's all documented, so no worries in case you want to try it out. Um you'll find your way into that.

So, that is the um actual uh REST interface. So, we see our flux compensator ECUs online. Um when we now try to read session, we're we're not allowed. We don't have any token. And then I wrote a little script that is authenticating us. It takes us into Google. we can choose a choose an account. I'll need my phone that says to verify that's actually me. And then

we can continue. And as soon as we have the authorization code, we can paste it into our little shell script and it's doing some things. Um So, basically it's calling the the callback um endpoint. We saw how it's registered. It's passing the authentication code. Then the ECDA is calling back to Google and exchanging that authentication to uh code with a token. And then the script is also

trying to lock the ECU. And then if we oops copy that access token into our clipboard, we can add that here. you can see I'm very well prepared. So, oh, I messed that up. So, give me 1 second. Because the URL is actually named like the service, so we can copy it from our um YAML file, so it doesn't matter if you mess up your prepared demo.

And you can see the last was Dr. Emmett Brown. the other service is um the read temporal technician uh the last temporal dump date, sorry. and we can see here our user is not allowed because it doesn't have the development rights. And if we take a look into our if I happen to find it. If we take a look into our conf Yeah, let's just search for

the email. Um then we see that my user is only an after sales user. So I'm not a developer as it seems and I can't access the rule. And we could change that to development and reload the configuration and then we would be able to call that service. But as I don't want to steal the last 10 minutes from Tilo I'm going to spare that you >>

Yeah. >> and let's continue with >> with slides, yeah, because >> the boring stuff. Oops, I have the clicker somewhere. >> I have the clicker here and I'm selecting the correct slides for you. >> Wonderful. >> So thank you Tilo. Take it away. >> So did you notice the flux compensator still uses UDS? So we have to do something there. Uh yes. So just I want to

just spend couple of a few minutes on on um talking about um what we besides the tech tech do um in or try to do in Open MR aim to do do there um is like as I already mentioned um take what we learn while we implement all these things um and work with the flux compensator put that into the standardization of SOVD, right? We have a

first version of and that is going to evolve over time, right? And what we want to do there is put things that we discovered along the way and into the standard. Of course, running it through the committees and putting into standard D's and you know, make it an ISO wording kind of ISO standard wording. But yeah, things like the SOVD server topology is largely discussed like how

do we order entities? What is the tree there, right? Things like things that we learned from the SCDA that I I have listed a couple of them here on the Um, These are all is all stuff that you just can know when you were actually doing it, right? And so one of the great things of Open SOVD is that we do these things and learn these these

points and can improve the standard and make it a better standard evolve that over time. Couple words on why this works exceptionally well in open source is because we have a community and a couple of people coming together just like Alex said, we got feedback on our protobuf implementation like hey, do you consider flat buffers somehow? And and that only works because we are getting together with

other people and not have our own echo chamber, right? And and learn from them and improve together. So, more more brains on the project means a better project and better implementation in the end, right? And in the end is the it's trustful collaboration there. We don't need to take lead on just everything because people are joining and organic organically choose their topics and things that their hearts

are attached to and enrich the project there. And through that we gain innovation, learnings, standard evolution, all these things. Um Yeah, and with that I guess I just can call to action. Try it out. Test the flux compensator and contribute on GitHub. We have like a QR code up there. You will land on our GitHub organization. Um you can join our meetings. We have couple of them

every week. Architecture board is probably the central one where you can just drop in uh discuss overarching topics or your entry to the project. And yeah, or dive in the code, leave comments, do reviews, what whatever, right? We will be around at the conference. Talk to us if you want to engage. Drop us a mail, whatever, right? Um Follow the QR code. And with that I want

to end and say we're in this together, we as an automotive industry. So, we have the chance to build exceptionally cool code in an our open source community and through that evolve the standard and let's do this together. Thank you, >> Thank you, Thilo. Thank you, Alex. Very very very cool stuff that you guys are doing. Can I get one of those Mercedes? Any questions from the

audience before we break for coffee? >> In case I want to add the flux compensator into my car to try things out, do you have the demo somewhat visible or another demo or tutorial to get started with S OpenSCD? >> So, um uh YAML that is not open source yet, but the the main reason for that is just because I didn't want to spoil the OSEX talk.

We will open source that as well. Um but the YAML file is actually based on the CD ice own test. So, we do have the ECU already defined via ODX tools, which is also another open source project. Uh so, you can take a look into the classic diagnostics adapter. There you find a bunch of Python files that generate basically the same ECU just uh the ODX tools

because they are more mature compared to the YAML implementation. >> And you mentioned that the classic diagnostics adapter is somehow related to the S-Core. So, it's part of it or so because you mentioned it on the slide. It says >> Yeah, classic diagnostics adapter >> Yeah, we tried to I So, we want where is it? >> The one the thing that Yes, one. >> Uh that one,

right? >> Ah, it's before the video. So, there you >> Yeah, so um as an overview to OpenSCD I just said we want to be integrated in um in Eclipse S-Core, which is currently not the case. Um we are working to towards that. Uh I believe that in in the near future you will see more activity around that. We try to organize talks between the two communities

that are somewhat overlapping but not totally, right? So we try to bring S-Cor and Open CBD folks together in the coming weeks and talk through this how this can be done and what needs to be done to achieve that. >> Thanks. >> And then by the way this is this not about only the CDA. So to be a an actual diagnostic subsystem in the in the middleware

or the automotive middleware we have to have more stuff like that you see on that slide like all these nice boxes there, right? Like SVD server and like a libraries that you can load into your applications to talk to these components to report faults or to execute diagnostic routines or whatever, right? That has all to be done which we call the fault lib and the fault manager

and stuff. All these things have to go into the diagnostic subsystem of a middleware increase a little bit on our on our momentum on on these components I guess but eventually we get there.