Communication CFT Weekly [2025-11-17]

[LittleHuba]

Participants

@LittleHuba
@darkwisebear
@lurtz
@sankurm
@mikehaller
@NEOatNHNG
@piotrchodorowski
@Abhishek2581
@alexandruiulian10
@kalu-an
@SebastianGrob
@badiiennouri1987
@FScholPer
@ZoranCutura
@dasoho
@mina-hamdi
Essam IMSAIL
Desoky Abdelqawy
Ahmed ElAbyad
Bharat Goswami

Agenda

1. mw::com in the GW. Should this be done to encapsulate the SOME/IP-Stack or does the lead to further resource waste (Jochen Speck)
2. Platform Autosd Relationship (@FScholPer)
3. Compiler flags (@FScholPer)
4. Should we discuss a migration to different communication APIs at this point in the project? (CommonAPI, raised by @mina-hamdi)

Meeting Minutes

1.

mw::com is similar to AUTOSAR ara::com API and should therefore be a good fit for an abstraction (@LittleHuba )
We also allow other applications to use SOME/IP standalone if they cannot use the gateway for some reason (@LittleHuba )

Communication between the gateway processes must happen via mw::com (this was an architecture community decision)

Each method call will block a thread of the gateway. (@JochenSatETAS)
-> This may make it hard for an integrator to configure the size of the thread pool
-> Priority inheritance requires synchronous

Why did we not yet work on async method API (it would solve above problem)?

• We focused on synchronous API to get a first version out
• C++ is not shifting to a new concurrency framework with C++26. Implementing an older standard makes from codeowner PoV no sense. Framework should be backported instead within S-CORE.
• We will discuss what the best approach is in a future discussion in the architecture community

=> We have only a subset of the SOME/IP features implemented in mw::com but this subset is anyway our restriction for IPC.
We plan to extend the the feature set

2.

Skipped on request of @FScholPer

3.

Compiler warnings are defined for the toolchains
How shall we treat that?
We want a description why each flag is set (why do we want it?) (@LittleHuba)
Compiler warnings shall only be set by the toolchains and not by modules (@lurtz)

• Modules may request compiler warnings to be added to the toolchain)
• We want a common minimal subset (changes to this subset is a breaking change) (@NEOatNHNG)
• We want a common strict subset (changes to this subset is a breaking change) (@LittleHuba)

Note: Compiler warnings are defined per language.

@FScholPer will bridge this topic with the infrastructure community

Other compiler flags:

Postponed to next session

Rust development before general qualification (topic from architecture round)

Risk and impact assessment necessary for using Rust before it is qualified

Risk is manageable but impact is big. We would have to fully reimplement the ASIL-B part of the gateway.
No impact from our side outside of the gateway.

For the moment we start on working on the QM part in C++ (this would be always C++ because mw::com and vsomeip is in C++).
ASIL-B part is postponed as long as possible, so that we might have better insight in the status of the qualification.

Support wanted from the various companies to get Rust qualified.