Communication FT Weekly [2026-11-02]

[LittleHuba]

Participants

@bharatGoswami8
@Thomas-Mikhael
@JochenSatETAS
@artem-rudskyy
@lurtz
@jorgecasal
@basheerFZ
@NEOatNHNG
@crimson11
@LittleHuba
Ahmed Tawfik
@soldier-sky

Agenda

1. Status update SOME/IP
2. Status update Flatbuffers
3. Status update Rust API
4. Status Methods&Fields
5. Status CI/Infrastructure
6. Open bug tickets
7. Short notice topics

Meeting Minutes

to (1)

@lurtz
IPC implementation replaced with LoLa based on GenericSkeleton/Proxy
Next steps to slim down SOCOM

to (2)

Update Runtime::Initialize() for strategy selection by Thomas-Mikhael · Pull Request #1435 · eclips…

CI Commit (Feature Flag Groups)
Update Runtime::Initialize() for strategy selection by Thomas-Mikhael · Pull Request #1435 · eclips…

@Thomas-Mikhael is on vacation for a week. A colleague will react if changes are needed.
Initial review requested.

to (3)

Rust::com Update score_com_concept test dependency cycle - eclipse-score/communication#1491

E2E Rust side - eclipse-score/communication#1062

to (4)

No timeline for eclipse-score/communication#767 yet.
Focus is currently on bringing message_passing up in the safety sentinel.
If an earlier fix is required, please raise this in the bug ticket. We are also happy to review contributions with a fix.

to (5)

QNX workflow quite unreliable from forks. This is the well-known problem of accessing secrets from forks.
@LittleHuba will contact @nradakovic to discuss how we can improve the situation now that we can host our own SDP in S-CORE infra.
Starlark linting is not yet merged. Waiting for some upstream changes.

to (6)

@LittleHuba will take a look asynchronously

to (7)

v0.6.0 was released. Check GitHub for the release notes. v0.6.0 is integrated into the reference integration (v0.1.0 release candidate).

--
SOME/IP stack from LG:

Safety Qualification for the lg-someip stack in regard to ASIL-B?
LG will follow the qualification approach of S-CORE (Safety sentinel as part of communication repository).
SOME/IP stack will remain QM since on the supported platforms we cannot use network in an ASIL-B level process.

Question raised by @NEOatNHNG: Do we need a separate process for the daemon?
No, the architecture will stay unchanged.

Question: What about maintainership and support of stacks?
We only support ONE stack and LG is willing to do longterm maintainership of this stack.

Why switch from vSOMEIP?
Mainly open questions are boost, performance and build system.
Fixing/Aligning these points will lead us exactly where the lg-someip stack is already at.

Decision: The architecture for the SOME/IP support remains unchanged. We solely exchange vSOME/IP stack with the lg-someip stack. This switch is agreed on based on the assumption that the lg-someip stack is a drop-in replacement for vSOME/IP and requires no additional daemon process.

--
E2E

HistoricalHealthCheck based on fixed cycle poll scheme.
-> Breakout session to be scheduled by @LittleHuba : participants @JochenSatETAS @LittleHuba @soldier-sky Ahmed Tawfik
Wednesday 2026-11-04 10AM German Time
Agenda:
HistoricalHealthCheck (what to do with missed samples?)

How to handle samples where the data integrity was violated?
Return a nullptr (invalid) sample ptr.