Communication FT - SOME/IP [2026-08-24]

[LittleHuba]

Participants

@crimson11
@NEOatNHNG
@lurtz
@LittleHuba

Meeting Minutes

Motivating PR: eclipse-score/communication#854

socom API

Main motivation of socom:
Enable reuse between gateway and binding use case
Abstract communication pattern between network daemon and gateway/binding

Evaluation of different architectures:
https://eclipse-score.github.io/inc_someip_gateway/main/architecture/dec_someip_api_abstraction.html

Reasons to not use mw::com API as abstraction:

• Service Orientated Communication is not a good fit for this problem (main problem)
• Strong typing of API more hindrance than benefit
• Configuration management too static
• GenericSkeleton/-Proxy not evolved sufficiently

Decision: We need a separate Abstraction for this use case

IPC bridge

socom has an IPC bridge that builds on message_passing & shared_memory
https://eclipse-score.github.io/inc_someip_gateway/main/architecture/dec_ipc_implementation.html

Main open questions regarding the bridge:

1. Do we want to have two IPC mechanisms? (to be answered based on questions below)
   • Additional maintenance effort (~6000 LOC)
   • Qualification effort of IPC brdige high (mixed criticality)
2. Would method support in LoLa change something irt the decision to not reuse LoLa? (@crimson11)
3. Would type erasure on binding level change something irt the decision to not reuse Lola? (@crimson11)
4. Is mixed criticality of binding use case sufficiently covered by socom? (@lurtz, @NEOatNHNG)

Follow up session on Tuesday 1st September 13:05-13:55
https://teams.microsoft.com/meet/39599705746130?p=4aUEcRbbaRcEfDWMHs