SOME/IP in S-CORE [2026-09-04]

[LittleHuba]

Participants

@NEOatNHNG
@lurtz
@pawelrutkaq
@crimson11
@LittleHuba

Agenda

1. Presentation of a proposal to use mw::com with LoLa as IPC mechanism within socom (by @crimson11)
2. Presentation of an updated architectural view for SOME/IP Gateway and Binding usecases (by @LittleHuba)

Meeting Minutes

to (1)

See attached proposal
LoLa_for_SoCom.md

Minutes

@lurtz mentioned that the current ipc bridge is in bad shape. Therefore, it would need a rehaul anyway.
Directly switching to mw::com and LoLa is thus okay from his side.

@NEOatNHNG raised the risk that we might now loose data between someipd and gatewayd.
Currently the communication between someipd and gatewayd blocks when queues are full.
By default mw::com does not do that.
This might be problematic for TCP based SOME/IP communication.
No definitive mitigation was defined in the meeting.

@pawelrutkaq suggested we extend Send API to provide an error if no space in FIFO is available
This was declined by @crimson11 because this does not work with IPC semantics.
Any solution would have to be on application transport protocol.

Michael and Ulrich will each get feedback from their company on how to handle this.

Note from @LittleHuba while writing the minutes:
Based on public SOME/IP specification there is no guarantee for events (even when transported via TCP) to be delivered to an application (TCP based guarantees end at the socket buffer).
Loosing samples would therefore be within specification. Still, reducing the risk of lost samples between gatewayd and someipd should be investigated.

@NEOatNHNG raised an additional concern:
A QM sender (someipd) may modify memory at any time after sending the data. The ASIL-B recipient (gatewayd) would need to do a copy of the data before E2E verifications are performed.
The following discussion highlighted that this is a general problem of using shared memory. A resolution would require that the sender looses write privileges on the memory area while sending. This involves OS-specific kernel calls.
The current assumption is, that doing a copy on a SOME/IP message is cheaper than doing 3+ kernel calls per message.

If this must be reevaluated there are some options:

• https://www.qnx.com/developers/docs/8.0/com.qnx.doc.neutrino.prog/topic/process_secure_buffer_mgmt.html
• https://newsroom.arm.com/blog/memory-safety-arm-memory-tagging-extension

@pawelrutkaq mentioned that currently mw::com only allows no concurrency for message calls on a single method in a service offer. This is very limiting in this use case.

@crimson11 separated this into two distinct problems:

1. Currently method calls are serialized on skeleton side since there is only one worker thread (tracked by Bug: Method call within a method callback handler not possible communication#767)
2. Proxies have queue size of 1 (can be lifted in the future)

Additionally a fully async implementation of methods may also resolve this.

to (2)

@lurtz sees the need to handle different bindings dynamically. A: When we really need this, mw::com is the appropriate layer to be extended to support loading bindings dynamically.
@lurtz also raised that we may need to support different SOME/IP stacks:
-- Yes, but in reality there is ONE stack deployed only

Explanation of architecture by @LittleHuba:
-- E2E will be used more common (LoLa/SOMEIP). Some parts of it will go into frontend to be shared.
-- Q from @lurtz: Will SoCom API survive? To some degree -> the comm-protocol part, which defines WHAT will be communicated will mostly stay. Additionally we will require as part of the comm-protocol an API that someipd will use.

Next steps for SoCom:
--- 1st replace the IPC layer with score::mw::com/LoLa.
--- 2nd step: Then we see, what needs to change/what is left from existing SoCom.

[LittleHuba]

Minutes from the follow-up meeting on the 2026-09-07:

Participants

@crimson11
@pawelrutkaq
@lurtz
@LittleHuba
@NEOatNHNG

Minutes

Recap of the above proposal

@NEOatNHNG feels like this is very similar to the proposal from one year ago.
Concerns are:

• Reusability of the code with different SOME/IP stacks.
• Multiplexing approach may be difficult
• Configuration handling (no configuration for GenericSkeleton/-Proxy necessary, additionally solved by API extension to load additional configuration at runtime)

@crimson11 will check once more for GenericSkeleton. Expectation is that no config is needed.
Minimal configuration may be required for communication participants. But this configuration would remain stable over runtime.

Major difference between socom and mw::com is that socom allows creation of proxies upfront before a service appears.
This simplifies the memory allocation strategies in ASIL-relevant code.

@crimson11 stated that this is also already present on IPC side of the gateway where proxies would have to be spawned adhoc.
Memory allocation problem needs to be fixed in either case.

@LittleHuba irt reusability of different SOME/IP stacks: The comm. protocol still is present to provide a reusable API. We expect that this API is general enough to support many SOME/IP stacks.

@lurtz What are the sizes of GenericSkeleton events?
@crimson11 GenericSkeleton expects in its construtor API a set of metadata elements mentioning what elements the interface contains including sizes and alignment of the data types to be transferred.
GenericProxy uses this metadata to find out what information is provided and how to correctly hand it over to the user. This is exposed to the user. So no manual side channel is needed
@LittleHuba on a higher level it depends on the mapping how well samples are fit into their slots.

@lurtz currently favors a 1:1 mapping of SOME/IP service instances to GenericSkeleton. This simplifies state handling which @lurtz would like to get rid of in socom.

@lurtz we will need an additional service for handling service discovery requests to the network.
@crimson11 yes, this is something to look into.
@LittleHuba We also currently redesign our service discovery to a daemon based approach. The current implementation creates to many problems. This new implementation could then also be part of the solution we require for SOME/IP.
@NEOatNHNG currently we already loose SOME/IP service requests on IPC level, since the gateway cannot intercept the request.
@NEOatNHNG initial handshake between gatewayd and someipd to transfer the list of required services. This list is not modifiable afterwards.
@LittleHuba alternatively you can use a static list for the full expectations of the applications behind the gateway/daemon.

@NEOatNHNG Subscription will have to be an explicit step. This can be solved via method calls.
@crimson11 this service can be a typed skeleton/proxy (Generic* do currently not work with methods)

Summary:

• socom will still exist in the end. The extent will be reduced, since pieces are handled by mw::com.
• complex API contracts will be handled in the comm.protocol layer (one place to implement for highest reuse)

What option to implement for the multiplexing strategy?
@lurtz @pawelrutkaq @NEOatNHNG @crimson11 @LittleHuba favor option 3
Later optimizations that go into option 1/2 will be based on actual data.

Next steps:
Modify socom to be based on GenericSkeleton/GenericProxy with multiplexing following option 3 (@lurtz, @NEOatNHNG)

[pawelrutkaq]

One hook from the meeting. Did anyone think of mw_com Allocate handling for SOME/IP binding?