Rust SIG Meeting 2026-01-20

[PLeVasseur]

Hey folks 👋 welcome to our first meeting of 2026.

Rust SIG Meeting 2026-01-20

Agenda

1. Solicitation of notetaker
   • @PLeVasseur
2. Acceptance of Previous Meeting Minutes
3. Rust Watercooler Chat Topic - Building safe Rust Bindings atop ASIL B C++ Middleware; Markus Hosch; BMW
4. 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.
5. Office hours - Rust + Automotive questions - come chat! (All)
6. Discuss upcoming events / news related to Rust & Automotive (All)
7. Meeting close

Check-in area

• @PLeVasseur
• @rama492
• @krucod3
• @darkwisebear
• @evshary
• @perrymcmanis144
• @terechko
• @AntonSchmukel
• @bharatGoswami8

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

• <task>

Meeting Minutes:

Acceptance of Previous Meeting Minutes

• Accepted

Rust Watercooler Chat Topic - Building safe Rust Bindings atop ASIL B C++ Middleware; Markus Hosch; BMW

• Challenges with using AUTOSAR in the past, since it could be used piecemeal which would allow for certain parts to have stronger guarantees / support than others
• To be fair to AUTOSAR, it didn't start at the paper level, but had bits-and-pieces of a reference implementation. Somewhat minimal though.
• The idea of Eclipse S-CORE is to have requirements and traceability, but also to have open source implementations.
  • https://github.com/eclipse-score
  • https://eclipse.dev/score/
• Using Bazel + bzlmod to allow pulling in pieces as needed
• It's still early when it comes to creating these Rust bindings on top of LoLa / Eclipse S-CORE's Communication
• Eclipse S-CORE made an early decision to have support for two languages:
  • C++ (
  • Rust (new, there's thought that it could be a good companion to C++)
• Therefore, both Rust and C++ interface is required for each software piece in Eclipse S-CORE
  • Makes it necessary to create hopefully, relatively thin binding / wrapper
• Will show today some of the internal work that will get synced to the Eclipse S-CORE repo
  • Near future will see removing this step with @darkwisebear having maintainership of the Eclipse S-CORE Communication repo
  • Two IPC frameworks were under consideration: Eclipse iceoryx2 & LoLa
• IPC cost ~15% of the CPU time for BMW moving one generation to the next, which gave inspiration for creation of LoLa (Low Latency shared-memory middleware)
  • Ultimately decided upon LoLa for cost containment reasons
  • There are certain aspects of the LoLa API which allow zero-copy shared-memory which will be gone into
    • Methods, Fields, RPCs, Events, as concepts which will be discussed
  • Primary goal of LoLa was to support Events
    • Most IPC is by means of data streams in Adaptive and Classic AUTOSAR
    • Via cycles or change-based
    • Could be as small as temperature, up to something as large as a Radar grid of EM clusters
    • That gives rise to the requirement to be zero-copy
  • Was meant to be a drop-in replacement to AUTOSAR Adaptive Platform interface communication
    • Fine since BMW is a member of the AUTOSAR Consortium
  • LoLa used in Automated Driving Level 3 environment (i.e. both lateral and longitudinal control, with the system supervising and warning driver if need to take over)
  • @darkwisebear (Markus Hosch) then begins showing his IDE to show some of the details on how LoLa and the Rust binding works. See here, in particular API Design principles
    • Builder pattern allows for configuration prior to truly initializing the system
      • Allows for flexibility and extensibility
    • All elements should be mockable. Users of LoLa / Eclipse S-CORE Communication should not need to insert their own mocking infrastructure for it.
      • Adaptive AUTOSAR didn't pay enough attention, which made it hard. Had to inject code. Required a good deal of tooling effort around mock generator and it's technically not the same code.
    • Strive for using Rusttrait objects to allow for additional flexibility
      • Code generation will not change, even if using different concrete implementations in test vs production code
      • There may be some differences, but striving for it
    • During initialization phase allow for allocation of heap objects, but prevent this at run-time outside of preallocated memory chunks.
    • Support data provision in potentially uninitialized memory for efficiency reasons, in a controlled fashion.
    • Want to be type-safe at the front-end level, but it's fairly likely the "back-end" not used by users is not type-safe.
      • "front-end": user-facing side
      • "back-end": the transport-level for shuffling data from one entity to another
      • Type erasure and FFI mean lots of unsafe, so in practice the "back-end" ends up yes, not being type-safe
      • Data may not outside data outside of its provenance

Detailed Walk-through

• Builder trait which allows for configuration at initialization time for an object to be available at run-time

• Runtime trait which lets the user talk through for performing IPC and must be implemented per technology to enable IPC

  • find_service: find a service, given the instance_specifier
    • Usually you know what you're talking to, but there's also the ability to use Any, e.g. if flashing software then be able to collect everyone and push it over
  • producer_builder: to allow for building a producer that will offer up something

• ServiceDiscovery trait which allows for querying of instances: get_available_instances() or async: get_available_instances_async()

  • async allows for you as a developer to gather up all of the instances to continuously get all of them
    • or allow you to at initialization time to async await on this to know you have a certain service up for you to progress to initialize

• ProducerBuilder trait which allows for further extension points, such as auto reconnection features of a server

  • e.g. for underlying layer to ask for reconnection

• Interfaces trait which is implemented for any technology that supports IPC in terms of the Consumer and Producer.

  • This enables e.g. the ability to have parameterization over Consumer and Producer having different Runtime, e.g. LoLa interop with iceoryx2

• Subscriber trait which allows for subscription to certain Events

  • trait bounds on it for Reloc bounds for the ability for moving data from one ECU to another, i.e. probably different address range
  • trait bounds on it for Send allows for moving one subscriber one thread to another
  • trait bounds for TypeInfo to allow for the underlying LoLa framework to do type erasure
  • subscriber() allows for obtaining a Result<Self::Subscription>
  • new() allows for choosing per element of an interface that you want that data
  • try_receive() allows for asking if something is present, as a &'_ mut SampleContainer<Self::Sample<'a>>>
    • This is important to allow for checking for potentially large samples, e.g. radar grids
    • Without losing previous, old samples
    • Important to allow for the ability of algorithms to have e.g. N samples at all times
    • Driven by concrete customer needs; may institute another API
  • receive() allows for polling in the Rust-sense
    • returns a Future and will wait till N samples are available
  • In future having another

• Consumer trait is nothing but a full interface used on the consuming side, just to disambiguate with Subscriber

Questions

• Below this level is C++, how do we go about that in the Rust layer?
  • Using a lot of code generate and reflection
  • Describing all C++ items in terms of descriptions: type-id, size
  • User need not look into the details
  • Framework does a majority of the work
  • For data types, strong recommendation to use something like bindgen
  • Runtime checks are also performed on type-ids, sizes, but not a perfect check. Raises chances of detecting an issue.
  • Some defensive programming in this layer? Yes, but can only be done at certain points.
• How about C++ interop?
  • Using cxx, some types from there are used

Material

Any material to read before the meeting should be included here.