Communication CFT Weekly [2025-05-05]

[LittleHuba]

Participants

@alexandruiulian10
@armin-acn
Kaluza Andreas
@timkl7
@crimson11
@LittleHuba
@ZoranCutura
Markus Hosch
@qor-lb
@arsibo
@FScholPer

Agenda

1. Discuss feedback to slides presented by @crimson11
2. Presentation of API change necessary to support FEO by @LittleHuba
3. Current state of Feature Requests
   • JSON parser @alexandruiulian10
   • SOME-IP gateway @ZoranCutura
   • InterVM @timkl7
   • CommonAPI / Franca by Valeo next week
4. Sync between Rust and C++ workstream
5. Request for all participants to add name to Github profile and get added to project

Meeting Minutes

to 1:

• https://github.com/orgs/eclipse-score/discussions/1005#discussioncomment-12978628

  • Does scheduling (throtteling, debounce) need to have a representation in the API? Do we need to set the corresponding properties dynamically per topic?

    • Configuration if necessary will be placed in runtime configuration
    • Throttling is part of how the user application calls the API, but there is also a lower layer throttle for draining network buffers
    • Quality of service metadata may be required to be transported to user applications (break with IPC API)

  • MACsec: Do we need it as part of the stack? https://eclipse-score.github.io/score/main/requirements/stakeholder/index.html#stkh_req__dependability__security_features

    • What concepts do we want to support? We can not support all of them.
    • MACsec is mentioned in the requirements -> Mechanism should be added
    • We want to stick for now to SOME/IP with SecOC

  • Do we need another transport next to shared memory to support low-latency/high-throughput inter-partition communication on top of a hypervisor, or can we assume that shared memory is supported and accepted across partitions?

    • To be considered in Inter-VM Feature Request

  • The integration of parts of the stack into QNX io-pkt makes these parts OS-specific. How about other Linux safety supporting OS'es like RHIVOS (Red Hat in Vehicle OS) or EB-LISA (Linux for Safety Applications)? Is there a decision in S-CORE to focus on QNX?

    • Yes, for the moment there is a focus on QNX. But we are open to also support other OSs and provide performant approaches for them.

• https://github.com/orgs/eclipse-score/discussions/1005#discussioncomment-12981603

  • VM To VM communication

    • QNX Hypervisor integration -> Using Vsock as one option?
    • Virtual Interrupt needed?
    • To be considered in Inter-VM Feature Request

  • Do we already have a filtering or rate limiting?

    • To be revisited once the code is open sourced and SOME/IP FR is available

  • Differences between datatypes(order,compiler, compiler flags) have to be addressed

    • Feature Request for ABI compatible datatypes #917

  • 1:n communication is often when states are shared in the system. So specific to domain can be often the case.

    • Relevant, support necessary

  • There are edge cases sending out data ipc and network at the same time.

  • Usecase high bandwith streaming

    • Low latency high throughput -> zero-copy/fewest-copies-possible
    • testcase in the future to verify performance
    • Some usecases will likely not use mw::com (e.g. video streaming)

  • External communication through dds or zenoh protocol or usage of dynamic transport like in uProtocol

    • Focus on other protocols once SOME/IP finished

to 2:

See https://github.com/orgs/eclipse-score/discussions/861#discussioncomment-13040972

• Proposal: Allow GetNewSamples() to get samples starting from a specific timestamp
  -> Directly leaking the timestamp to user applications is restrictive for the future (could also be encapsulated)
  -> This API is more restrictive, since you could not retrieve samples 1,2,4,5 without 3
• Proposal: DDS has a solution for this
  -> Kaluza Andreas will post DDS specification for RTPS
  -> Once we have the relevant documentation we will consider whether we go with the linked approach or a DDS-like approach

to 3:

Warning

Not discussed in this meeting -> will be shifted to next meeting

to 4:

Warning

Not discussed in this meeting -> will be shifted to next meeting

• Rust workstream will focus on feature comparity with C++ API
• Any divergences in the API will be noted down as tickets, to sync C++ and Rust API afterwards
• C++ API will for the moment stay mostly stable until more pressing issues for v0.5 are taken care off (see S-CORE Roadmap (view))
• @crimson11 currently working on design for method support
  • workshop to dicuss design and API effects for Rust once design is finished

[kalu-an]

-> Once we have the relevant documentation we will consider whether we go with the linked approach or a DDS-like approach

• RTPS specification is public and can be derived in current version 2.5 here DDSI-RTPS
• DDS vendors claim to support zero-copy, IPC transport, ASIL certified
• Eclipse Cyclone DDS is using iceoryx for IPC

In general it is

• about PIM (= Platform Independent Model), PSM (= Platform Specific Model), Service Discovery and Wire Protocol
• using SN (= SequenceNumbers) for data samples, analogy to TCP sliding window
• DataWriter is sending HeatBeats
• DataReader is sending AckNack
• bevor data is making it from DataWriter to DataReader both must agree on QoS (= QualityOfService)

There are 22x QoS policies e.g.

• Controlling which entities "match" and communicate -> scaling
• Controlling reliability and priority
• Accessing historical data applications which need to cache some data and make decisions
• Working with time-sensitive data
• ...

sequenceDiagram
    title RTPS - Relibilty

    participant Writer
    participant Reader

    Writer-xReader: Data(writerId, SN_x, payload)
    note right of Reader: SN_x gets lost
    Writer->>Reader: Heartbeat(writerId, readerId*, SN_low, SN_high)
    Note right of Reader: SN_low ≤ SN_x ≤ SN_high
    Note right of Reader: readerId*: case known or ENTITYID_UNKNOWN for all readers
    Note right of Reader: SN_low, SN_high: range of data which DataWriter has
    
    Reader->>Writer: AckNack(readerId, writerId, SN_ack, SNS_nack)
    Note right of Reader: SN_ack ≤ SN_x, SN_x ∈ SNS_nack
    Note right of Reader: SN_ack: positive confirmed sequence numbers
    Note right of Reader: SNS_nack: negative confirmed sequence numbers
        
    Writer->>Reader: Data(writerId, SN_x, payload)
    Note right of Reader: DataWriter resends the data

    Writer->>Reader: Heartbeat(writerId, readerId*, SN_low, SN_high)
    Reader->>Writer: AckNack(readerId, writerId, SN_ack, SNS_nack)
    Note right of Reader: SN_ack > SN_x
    Note right of Reader: AckNack: DataReader confirms all SN 
    Note right of Reader: No more Heartbeat needed for this data

Loading