SOME/IP Gateway design

[lurtz]

@pawelrutkaq
@mina-hamdi
@NEOatNHNG
@badiiennouri1987
@lurtz
@LittleHuba

Topics

Use GenericProxy & GenericSkeleton to keep generated code at a minimum

• GenericSkeleton needs to be written in C++ in mw::com
• Code generation is considered a bigger pain in the ass than GenericSkeleton
• QNX safety manual does not allow dlopen() in combination with C++ features (e.g. typeid)
  • usually new images are build and flashed on ECU updates
• too much type safety will increase code size

Starter SOME/IP stack

• vSOMEIP is the stack of choice due to its availability

Starting code base

• proposal take bazel setup from ETAS
• code from Qorix
• use for Rust code newest mw::com API design (might not be finished yet)
  • https://github.com/eclipse-score/inc_mw_com/tree/main_api_rs

IPC protocol design

Assumptions:

• two processes (SOME/IP stack (QM), payload transformation (ASIL-B))
• they communicate via mw::com
• SOME/IP messages (header + payload) with different sizes
• mw::com slot sizes are defined at compile time for typed Skeletons
  • GenericSkeleton could do it at runtime
• Startup order should not matter
  • still need to avoid deadlocks

Option 1 (Tunnel):

• define SOME/IP protocol abstraction on top of mw::com
• biggest SOME/IP message will define slot sizes for all
• single interface definition, no GenericSkeleton needed
• can support find service messages
  • however needs to be supported by mw::com anyways
    • mw::com tries to avoid service discovery storm from the gateway
    • SOME/IP gateway should only make service available locally, which are useful in the current ECU state
• shared memory can be shared by many services
• all SOME/IP messages are in the SAME queue
  • might lose data

Option 1.a:

• single service instance is used for all gateway IPC traffic

Option 1.b:

• each SOME/IP service gets its own gateway IPC service instance id: multiplexing with service instance ids possible

Option 2 (1:1 mapping):

• for each SOME/IP service a mw::com service sibling is created
• each service can use different slot sizes
• GenericSkeleton required or code generation
  • at construction of GenericSkeleton instance you can set the sample size and number of slots during runtime
  • might cause a delay during setup of a service subscription, which is accepted
  • delays after setup are not acceptable
• requires more configuration tooling
• mw::com manifest must be configured accordingly prior startup
• dormant but active services will consume shared memory slots
  • gateway would double the amount of memory required for these services
• SOME/IP stack and payload transformation might need extra control channel
• need Skeletons need to know if there are subscribers?

===>

Decision: go for 1:1 mapping

Find service / Service discovery

• Offer only services on the network which are available locally
• should the gateway upon startup subscribe to all configured services?
  • many services might not be needed depending on system state
• should the gateway subscribe to a service once an internal IPC client needs it?
  • need hooks to IPC service discovery and get notifications once an IPC client starts searching for a service
  • what to do with services which do not send periodic OfferService messages and only react to FindService messages?
    • or one OfferService at startup and this one is missed
• Service Subscriptions need to be eventually dynamic
  • Sender only sends data over the network upon subscription
  • might be important for e.g. video streams

===>

Decision: all configured services are subscribed to by the network stack

• needs to support on demand Service Subscriptions in the future, but not a necessity in the first iteration
• on demand Service discovery is optional

TODO

• @NEOatNHNG check QNX safety manual about dlopen() and C++
  • only extern "C" functions are allowed to be loaded
  • apart from that dlopen() is fine and C++ is fine

[lurtz]

@pawelrutkaq
@LittleHuba
@NEOatNHNG
@crimson11
@mina-hamdi
@lurtz

Topics

Rust in the SOME/IP Gateway

Rust is not mandatory anymore and we should focus on getting the feature done. Thus we only do Rust where it will not do harm, if Rust is not being safety certifiably by the end of 2026. See also the discussion in eclipse-score/inc_someip_gateway#1

To stay open to Rust we will first focus on defining the IPC protocol between SOME/IP stack and payload transformation processes.

Design of the SOME/IP Stack

Multiple options for implementation were discussed.

Option 1: SOME/IP Stack as mw::com binding

The mw::com binding API is kind of the plugin API, which needs to be implemented for SOME/IP implementations. Apart from that most code in the SOME/IP Stack code is reused.

Here the SOME/IP implementation would be one way with which mw::com transports its data and can be selected via configuration. This requires that additional bindings can be registered at mw::com (open closed principle). This functionality is currently missing at mw::com.

Option 2: SOME/IP Stack as socom binding

In contrast to option 1 socom is the API which needs to be used by SOME/IP implementations to interface with the SOME/IP stack.

socom is quite similar to mw::com, but simpler and already has an API to register bindings. It also supports methods. With socom a simple SDK can be created with which SOME/IP plugins can be created.

Option 3: SOME/IP Stack in own process

This is basically only implementing the IPC protocol for the SOME/IP Gateway processes and does not reuse code as option 1 and 2 do. This has the advantage that the chosen SOME/IP implementation might be used more efficiently or with less complexity.

TODO

• definition of IPC protocol
• mw::com API for adding bindings at runtime
• Rust qualification roadmap

[lurtz]

@pawelrutkaq
@LittleHuba
@NEOatNHNG
@mina-hamdi
@lurtz
@badiiennouri1987

Topics

Design of SOME/IP Stack

Will definitely need to define IPC interface

• Option 2
  • socom is seen as duplication of mw::com and will not be accepted (@LittleHuba)
• Option 3
  • can allow zero copy from SOME/IP implementation to IPC
  • ETAS and Qorix vote for this option

IPC Protocol Design

• mw::com might get additional binding for transporting SOME/IP semantics over IPC
  • discussion if that is necessary
    • people assumed logic for SOME/IP to be on top of mw::com
  • intention is to hide as much as possible via mw::com
    • SOME/IP service id to mw::com id mapping
    • possibly additional control channel
  • some applications might embed payload transformation themselves and bypass the daemon process

TODO

• everybody draws a picture about the SOME/IP Gateway design to sync ideas / understanding

[lurtz]

@pawelrutkaq
@crimson11
@NEOatNHNG
@badiiennouri1987
@lurtz

Topics

• concern that generic SOME/IP Payload transformation / gateway daemon has to have lots of customization points (even with plugins), which makes it quite complex
• should create building blocks to create OEM specific SOME/IP Payload transformation / gateway daemons instead
  • there will be likely one daemon per service interface
• SOME/IP binding responsibilities
  • should only communicate with the SOME/IP Network daemon
  • will do E2E checks
  • no payload transformation (will be done by OEM specific code)
• SOME/IP binding on top of or below of mw::com
  • problems with putting SOME/IP binding on top of mw::com
    • SOME/IP binding API would be semantically the same as the mw::com API
    • will require API changes to support E2E at the mw::com API

[NEOatNHNG]

[lurtz]

@NEOatNHNG
@lurtz
@crimson11
@badiiennouri1987
@mina-hamdi
@pawelrutkaq

Topics

• discussed tunneling or 1:1 mapping again
• do we need a control channel for service discovery between SOME/IP network daemon and its clients?
  • lola uses internally RPC which could be used for small to medium sized payloads, no need for mw::com methods feature
  • https://github.com/eclipse-score/communication/blob/84db3dfbc89cd59cec66513b4f49b8f0d73fbba8/score/message_passing/i_client_connection.h#L61C88-L63

TODO

• sequence charts showing IPC interactions between SOME/IP network daemon and its clients
  • service discovery
  • events
  • fields
  • method call
• still need to decide on which layer the SOME/IP binding should be done

[lurtz]

@lurtz
@NEOatNHNG
@crimson11
@pawelrutkaq

Topics

• need branch in communication on which we can work for the binding underneath mw::com
• mw::com API needs extension for E2E state machine checks and mw::com needs extension for loading E2E implementation
  • CRC checks can be done in the gateway daemon
• can we avoid a control channel and just use lola?
  • will require for event subscription extension to mw::com so that provider knows if there are subscriptions to do a subscription on the network
  • FindService will require a control channel, but we may do it later
    • instead we first subscribe to all configured services eagerly

MVP

first, minimalist

• eagerly subscribe to all statically configured services

• no E2E

• should this work without control channel?

• should we merge the pitch from ETAS?

  • then we should extend it to support any number of services

[lurtz]

@lurtz
@NEOatNHNG
@crimson11
@alexandruiulian10
@pawelrutkaq

Topics

We continue with the PoC from ETAS: eclipse-score/inc_someip_gateway#2

• already does some IPC communication between SOME/IP network daemon and payload transformation (Gateway)
• need to replace hard coded stuff with generic solutions
• needs GenericSkeleton in communication
  • @crimson11 suggests we do not need that
  • the SOME/IP binding underneath mw::com could use its own special place in shared memory
    • would not need a GenericProxy either
  • lola is optimized for 1:n communication, communication between network daemon and payload transformation (Gateway) is most likely to be unicast

  • all interprocess communication should be via lola ❓

  • reuse libmemoryshared, but not lola

TODO

• @lurtz contact eclipse and ask about the options we have for a feature branch in score communication
• @NEOatNHNG / @lurtz Check if we can use the companies contrib orgs if above response turns out to be difficult
• @crimson11 create design proposal

[lurtz]

According to @chheis we either have to become committers or work on a shared fork.

[lurtz]

@lurtz
@NEOatNHNG
@crimson11
@alexandruiulian10
@pawelrutkaq

Topics

• Design proposal from @crimson11 https://github.com/eclipse-score/score/blob/40063b8de1927ba07d2f50a66171f2c90688f237/docs/features/communication/some_ip_gateway/architecture/someip_network_daemon_design.md

[crimson11]

I did update my proposal here:
#2342

I incorporated the hints from @NEOatNHNG regarding generic proxy/skeleton usage.
I added also the reverse path: Receive a SOME/IP service instance from the network.

[NEOatNHNG]

We are depending on the GenericSkeleton implementation

[lurtz]

did you intend to link to eclipse-score/communication#76 ?