Rust SIG Meeting - 2026-04-14 #23

PLeVasseur · 2026-04-14T14:00:59Z

PLeVasseur
Apr 14, 2026
Collaborator

Hey folks 👋 welcome to our 7th meeting of 2026.

Rust SIG Meeting 2026-04-14

Agenda

Solicitation of notetaker
- Pete LeVasseur
Rust Watercooler Chat Topic - Putting Rust into practice in OpenSOVD; Elena Gantner - Mercedes Benz
Review GitHub repo content and discuss how to enrich (Pete)
1. Issues
2. Discussions are now active! We'll take meeting notes here based on previous agreement in the SIG.
Office hours - Rust + Automotive questions - come chat! (All)
Discuss upcoming events / news related to Rust & Automotive (All)
Meeting close

Check-in area

(we had about 15 people at one point, including the folks listed below)

Housekeeping section, please add

Document space: https://drive.google.com/drive/folders/1Ub0qTLKvTFilPC9TFVEdTyWn_9qJ-vYD?usp=drive_link
GitHub repo: https://github.com/rust-sig/rust-sig
Eclipse SDV Slack channel: #rust-sig

Tasks

Meeting Minutes

Putting Rust into practice in OpenSOVD; Elena Gantner - Mercedes Benz

Links if you're interested:

OpenSOVD is an implementation of the new ISO standard, as of next month.

Elena is working largely on the classic adapter portion at the moment

Demo of Adapter

Involves

ECU simulator with two ECUs
- This is also open
- Developed in Java and Kotlin
Adapter
configuration that's used for the simulator and the classic adapter

Showed in the demo:

possible to receive newer type of SOVD message in JSON
convert to classic representation for UDS
back to newer type of SOVD message in JSON

Also built terminal UI (TUI) that allows for inspecting all general and variants of messages (https://github.com/alexmohr/mdd-ui)

can help troubleshoot when there's a failure to look it up
- source identifier, subsource identifier can be double checked against
can check for positive/negative responses for expected response
can see ECU session type as an int, which then gets rendered nicely as a table within the TUI
reuses the database component of the CDA (Classic Diagnostic Adapter)

Going back to the terminal, can use command to see which services are available.

Can also check for and see authentication; can't demo that locally in her environment.

Strategy on architecture:

many smaller crates
cda-databse crate for example: reading database and allows for usage of database by implementing some traits

Format MDD:

Marvelous Diagnostic Description - MDD
still based on ODX
- ODX - defined in an ISO standard for how to specify ECUs - ISO 22901
wrapped in ProtoBuf/Flat Buffers
allows for memory mapping

Payload conversion benchmarks show on target hardware around 10 nanoseconds on complex payloads using FlatBuffers and mapped memory.

60 ECU descriptions loaded
ODX around 15MBs
MDD files smaller by about 1/3
RAM usage is around 200 MB during flashing ECUs and such
Just about all written in Rust; there's some other kinds of code in there, but 92% is Rust

A bit of C code:

default is using OpenSSL
some trouble using OpenSSL features
- extension to limit maximum frame size is not supported
- therefore have bindings to https://github.com/Mbed-TLS/mbedtls

Could be nice to have someone that has a security background or interest in sharing about thoughts on OpenSSL, mbedtls

Question: Does MDD follow some kind of standard?

Still based on ODX, somewhat restructured
Same constraints as ODX, presented in a different way
Main reason for reworking into MDD was to make decoding it more efficient from the point of view of RAM and disk size
- even compressed ODX is much larger than MDD using FlatBuffers
Initially was going to use ProtoBuf as the stand-in format, but now switched to FlatBuffers based on suggestion from colleague

Walkthrough of the code

Thorough use of generics in the codebase

upside: able to exchange parts easily as needed; has example of someone swapping in a nicer implementation
downside: new contributions are a bit harder
e.g. UdsEcu as a trait, which then has trait methods that an implementer would implement to ensure compatibility
only dynamic trait is the security_plugin; there's reasons/rationale for that which will be shared later

Wanted to remain agnostic to the kind of gateway

cda-core crate is then implementing the trait we saw before
data layers don't need to know how to read the data, so that's isolated here in cda-core

Code may be a little hard to read at first until getting used to how functional chaining works in Rust

Elena will share some examples later on the #rust-sig Slack channel

Data is kept in a format that's easily type-checked and can have invariants imposed upon it for the data processing, right up until ready to write to the outside world.

the conversion to the outside world turned out to be pretty complex
different customer needs for different formats, e.g. needs for ODX vs what's needed for SOVD
helps keep the complexity contained in the CDA (Classic Diagnostic Adapter) and not in client code

Communication Example:

cda-comm-uds: where the sending is implemented
takes a generic UDS manager
uses the generic gateway EcuGateway to send the data to the ECU

Communication Example:

cda-comm-doip
underlying TCP connection to implement
turned out to have not memory bugs, but instead some logic bugs causing deadlocks
"Happy to have chosen Rust" as tokio-rs allowed them to troubleshoot deadlocks using the tokio console
Had to encode ODX logic which requires certain number of retries in communication crates.
design decision made early on: try to almost never hard fail
- if message received that was not expected, we log it, and then keep waiting
- came about from testing in realistic environments where breakage when the unexpected occurs
- have the option to keep requests alive from previous even if the newer one is malformed/wrong
had problem with locks being required taking too long, so have some checks on the attempts to acquire them
doip-codec being used for definitions; have upstreamed some changes they needed
want to have separate sender/receiver tasks as they don't want to block either direction, so they use tokio::io::split() on the stream.

Bit of a walkthrough on usage of TLS now:

most ECUs don't accept a plain connection that's not TLS
if we get request for TLS connection then set up the socket with required options like cypher list
most ECUs use TLS only for authentication so the connection cannot be hijacked, and don't encrypt the communications

In vehicles can have gateways, but also giving a different target ECU that's behind some separate gateway over CAN/LIN, whichever connection.

Question: How did you find the Rust bindings over top of mbedtls?

Tried AI-assisted coding for this part
Found quite easy with mbedtls since it's C code
Has found that modern C++ code to be more challenging due to callbacks and such
Used bindgens for binding for the header
Had to do a bit manually that was statically inlined as funny things could happen there from what she heard

Question: I'd love to hear about the deliberation to choose Tokio. Was it because of popularity/network effects or were there specific things it offered over some of the lighter weight runtimes?

Originated as a PoC within Mercedes Benz
Elena was most familiar with tokio-rs already
Using Axum framework for web/SOVD parts
The tooling around tokio-rs was extremely helpful; do other runtimes also offer these kinds of facilities?
There were discussions around how agnostic OpenSOVD should be to runtime vs not
- Ultimately decided to embrace tokio-rs
- The chance that you find someone with similar problem was way higher than a less-used runtime
- tokio console was a big factor too; incredible tool
  - helpful to see which functions might be getting too large and causing issues on the stack
- reasons for other runtimes: smaller memory or disk footprint, so it made sense to still use tokio-rs for the HPC (High Performance Compute) in this case

Question: How did you manage to convince stakeholders to sponsor Rust usage?

Gathered in-depth knowledge folks on diagnostics, Rust
Used company mechanism to spend some amount of time on a proof of concept that was focused
- query/writing data, authentication on ECU
directly showed it running in the car
- seems to have made the biggest impact to show it working on the vehicle
having minimal dependencies on system
much, much faster to prototype than C++, especially if doing async work
pointed out previous version was using 10x as much CPU due to older code
polish and getting it to look impressive was important
having some coordination/collaboration with Eclipse S-CORE was helpful for its adoption there

Question: How was accepting Rust's async development model? Maybe most developers are not used to it?

currently still a small team, 3-4
was able to onboard them quite fast
were still issues with deadlocking; would be same multithreaded
acceptance was already quite high from the team, they were already excited to work with Rust
- one of the team members wanted to bring in the latest C++ standards work including async stuff
convincing with numbers by using tokio was a big factor in convincing others to take up and use async Rust
- if using normal multi-threading in C++ you'd kind of struggle at times to troubleshoot issues
not extremely complex, but need to manage the logic related to all the open connections

Question: Did you hit any kind of limitations of tokio-rs?

if you want to request timing of messages going out of < 1 ms you will get into trouble
luckily for the constraints on UDS communication have enough headroom of +/- a few milliseconds so this is fine
if you have very tight constraints having dedicated threads may be needed

Call to action for folks to open discussions/issues on the repos as-needed to get involved!