Communication FT Weekly [2026-07-20]

[LittleHuba]

Participants

@Thomas-Mikhael
@crimson11
@alberto-s-avila
@bharatGoswami8
@NemanjaTrifunovicRTRK
@Rutuja-Patil-Bosch
@alexandruiulian10
@JochenSatETAS
@NEOatNHNG
@esrour
@lurtz
@Abhishek2581
@sistlajr
@LittleHuba

Agenda

1. Status update SOME/IP
2. Status update Flatbuffers
3. Status update Rust API
4. Status Methods&Fields
5. Status DDS gateway
6. Status CI
7. Short notice topics

Meeting Minutes

to (1)

@NEOatNHNG
Socom changes are integrated
ITF introduced to gateway repository
Ready to start integration into the main communication repository

1. Restructuring to fit layout in main repo
2. Create a plan of what should be moved and in what order
3. Create PRs that move according to the plan (try to make them reviewable in terms of size and complexity)

TL circle has interest to get this integrated with v0.9
Current feeling is that this timeline will be too closely cut. We plan with 0.10 to give us some more time.
Even when integrated, this does not mean that SOME/IP support is feature complete.

to (2)

@Thomas-Mikhael
Merged:
eclipse-score/communication#615
eclipse-score/communication#634

Third PR is in progress

to (3)

@bharatGoswami8

• Field API design created - Rust::com Field APIs design and example of usage communication#700
  Request for review.
• Score Logging integrated on Rust API Lib - Rust::com Enable the logging support in Rust Lib communication#730
• Method Design is in progress, mostly by this week it will be ready.
  (Initial draft - Rust::com Method Rust APIs design and Example usage  communication#723)

Two topics:

1. Move public rust API out of the impl directory (@bharatGoswami8)
2. Clippy support is added in the CI (hopefully within the week) @LittleHuba

to (4)

Some testing PRs still pending in review.
Open issues:

• Getter and Setter support and the influence on the size of event slots
  • Power-user vs. beginner friendly configuration

to (5)

@Abhishek2581

New Comments were added. If a discussion is finsihed, please resolve it on Github for a clean history.

#2997 (comment)
Based on this feedback it makes sense to add a high-level architecture to the feature request.
This helps to understand some of the design challenges and solutions.
Please do not go into too much detail in the architecture yet, to not spend effort on things where we are still in discussion.
It is important to have a level of detail to understand what usecases shall be supported and what cases are not supported.

Sepcific request:

• Please add diagrams showing the dynamic flow
• Please discuss your use case and further supported use cases
• Please look at further open discussions.

See comment in PR about how binding and gateway approach interact.
Communication between the different pieces (application/translation/networking) are only partially restricted to specific solutions:
Application to translation via LoLa (for gatewaying) but consider that in binding approach this resides in the application space
For translation to networking try to reuse existing solutions (LoLa/message passing/SOME/IP-Gateway solution) but we are open for discussions on different solutions if you can not solve your use case with existing ones.

to (6)

Linter support upcoming, as discussed above.
Coverage baseline support is being introduced currently
Rust support still not raised by Qorix

Public API checker will be introduced:

• PR with work in progress: Ensure no breakage of public API communication#715
• Public API is selected based on Bazel visibility of a selected target and its dependencies
• APIs that shall not be public but are visible as C++ symbols must be put in a namespace detail or impl.

to (7)

InterVM gateway

Use case: Communication using S-CORE to communicate between two VMs on QNX Hypervisor
What we opensource is an example. This code is quite specific to hypervisors (e.g. needs adaptation to your use case)
We are quite confident that our example is adaptable to different hypervisors.
Common code base is extended to support this use case.

Meeting to be scheduled between @crimson11 and Nemanja Trifunovic, Sistla Janakiram @sistlajr, @NEOatNHNG / @JochenSatETAS
@Crimson will set up meeting

Documentation

Documentation landed:
https://eclipse-score.github.io/communication/latest/tutorial/chapter_1/README.html

Please provide feedback!

Kudos to ETAS for also contributing to a tutorial for heap allocation considerations (in review).
Chapter on how to write unit tests against mw::com is upcoming!

Support for Modelling Frameworks (Matlab/...)

To the knowledge of @LittleHuba this was not yet considered in the context of S-CORE.
Please reach out to @qor-lb for more insights.
https://sdvworkinggroup.slack.com/archives/D08A1AC6KTP

[Abhishek2581]

Hi @LittleHuba, Hi @JochenSatETAS :

I have updated the feature:

• Added a high-level architecture and clarified the responsibilities of the DDS Binding, DDS Gateway, and DDS Communication Daemon.
• Added dynamic flow diagrams for the service availability policies and E2E processing.
• Expanded the description of the supported deployment models and use cases, including the interaction between the Binding and Gateway approaches.
• Clarified the communication boundaries while keeping the translation-to-networking communication implementation-independent to allow reuse of existing solutions.

I believe the review comments have now been addressed. Please let me know if there are any remaining gaps or if additional clarification would be helpful.