Communication API Workshop (06.03.2025-07.03.2025)

[LittleHuba]

Participants

• Andreas Beetz
• @arsibo Arvid Sievert
• Holger Braun
• @MarkSchmitt, Mark Schmitt
• Markus Hosch
• Manuel Fehlhammer
• @HartmannNico, Nico Hartmann
• Ulrich Freund
• @LittleHuba, Ulrich Huber
• @timkl7, Tim Kliefoth

Location

Workshop is on-site only.

Mercedes-Benz Tech Innovation GmbH
Wilhelm-Runge-Str. 11
89081 Ulm

Contact:
Herr Mark Schmitt

Agenda

Do 06.03.2025 (10:00-18:00)

• 10:00-10:30 | Welcome
• 10:00-12:00 | Target Setting
• 12:00-13:00 | Lunch
• 13:00-14:00 | API Deep Dive mw::com
• 14:00-15:00 | API Deep Dive Iceoryx2
• 15:00-15:15 | Break
• 15:15-16:00 | API Deep Dive uProtocol
• 16:00-17:00 | Architecture (Layers)
• 17:00-17:15 | Break
• 17:15-18:00 | Architecture cont.

Fr 07.03.2025 (8:30-16:00)

• 08:30-10:00 | Communication topology (addressing, participants, transport scheme)
• 10:00-10:15 | Break
• 10:15-12:00 | Target API concepts and building blocks (Interfaces, Event, Signal, Method, Proxy, Skeleton, ...)
• 12:00-13:00 | Lunch
• 13:00-15:15 | Target API concepts and building blocks cont.
• 15:15-15:30 | Break
• 15:30-16:00 | GAP analysis

Preread

Rust

The ultimate starter kit: The Rust Programming Language
A quick read into Rust: Einführung in Rust (German)

C++

Templates: https://www.geeksforgeeks.org/templates-cpp/

[LittleHuba]

Meeting Minutes

Target Setting:

• Communication API as generic solution

  • independent of transport protocol
  • with zero copy capability

• Zero-Copy support is our focus

• Mixed Criticality

• Service discovery

• Access control

• Service Interface

  • Versioning
  • static grouping of communication elements

• Supported communication patterns

  • pub-sub (1:n)
  • request-response

• Communication elements

  • Event Type
  • Method
  • Signal
  • Field/Blackboard (value retainment) (out of scope for v0.5)

• Clear ownership of communication elements
  The framework does not just keep communication alive on its own.
  The user actively has to keep communication endpoints alive.

• Users do not need another API layer on top

• Declaration and definition as separated steps in API
  Setting up communication elements and starting communication are separate steps

• Keep cost of adoption/migration of/to S-CORE low

• KISS (keep it stupid simple)
  (- Asynchronicity is abstracted from the user where possible)
  (- User control over runtime determinism)

• Roles to consider

  • Developer
  • Integrator
  • Architect
  • Safety Manager

• Special use cases

  • Fail-over
  • Redundancy
  • Migration

Deep Dives

LoLa

• Not yet supported: Optional configuration in code, as alternative to code in json file
• Glue metadata (tags) to communication channels (clear use case not defined, no focus for now)
• Publisher is unaware of consumers (basic concept of pub-sub)
• Service discovery must be currently triggered manually, planned to be done automatically

Iceoryx2

• Builder pattern is interesting

uProtocol

• Certification not feasible, too many huge dependencies that would need certification (protobuf, tokio, ...)
• Potentially interesting as edge-protocol

Architecture (Layers)

• shared memory handling envisioned as a base library with shared memory providers for different SHMs

Layering

            Application
---------------------------------------
mw::com frontend (binding independent)
---------------------------------------
             Binding API
IPC binding (LoLa) | mock binding | ...
---------------------------------------
                  OS

Binding API: Each binding must follow a common API

• How to handle scenarios where network communication must happen via central daemon (port binding)?
  -> Broker

• Where to put encoder/decoder?
  -> Binding/Gateway

Change scenarios:

• Change in deployment
• Change in application interface
• Change in network service

Error scenarios:

• De/Encoding fails
• Network error

	App-local Enc/Dec	Enc/Dec in Broker
Creation cost	+ single responsibility	- high process cost
	- network know-how	- different entities involved
Complexity	- Change must be done by every app
Performance	- Decoding per each app	0 Pot. unneeded decoding with no consumers
		+ Single decoding
Scalability (com. partners)	See creation cost	See creation cost
Scalability (protocols)	- recompilation of each app	+ central change of deployment
	- deployment change
Resampling	+ receive (decode on demand)	- receive
	- send	+ send (only when necessary)
Testability	- different protocols for instr.	+ only IPC com for instrumentation
Integritiy	+ E2E check simpler	- no longer grey channel

• Encoding/Decoding may be
  • in app
  • a separate gateway between N apps and broker
  • in broker

=> Potential decision: Enc/Dec must be possible to shift
=> Since no further impact on API, we shift this decision to later after v0.5

Communication topology

Visibility restriction (a.k.a. scoping)

• Communication network partitioning

=> This is really a service discovery discussion
=> We can currently not determine the feasibility of scoping in a multi-protocol concept
=> We believe that scoping can be screwed on top of an existing service discovery

• For v0.5 we stick with the current flat service discovery of LoLa
• After v0.5 we start with the creation of a PoC for a scoped service discovery
• Based on the PoC we decide whether scoping will be integrated

Target API

• Runtime, Proxy, Skeleton, Communication Elements are first class citizens.

  • All must be instantiated with the builder pattern
  • Builders can be retrieved from the parent class (e.g. to build a Proxy, get builder from Runtime)
  • Runtime builder can be created adhoc
  • Divergence from current LoLa API!
    -> Check in LoLa necessary whether multiple subscribers are possible for a single proxy
    -> backup, error returned when user tries to build communication element more than once

• Strings are unicode UTF-8 (@LittleHuba bring to S-CORE technical lead circle)

• Asynchronicity -> For now we focus on synchronous API, async will follow in a later increment

  • Once we focus on async we need to consider the following conflict of interests:
    • performance (scheduler priority inheritance)
    • determinism (executor is used by com framework)

• Runtime/Skeleton/Proxy/Communication elements are not reentrant

• Runtime/Skeleton/Proxy/Communication elements cannot be copied/cloned

Buffer:

• Producer
  • Uninitialized buffer
    • cannot be sent, cannot be dereferenced, can only be written to
    • when written to, uninitialized buffer is consumed and initialized buffer is returned (consumption semantically not possible in C++)
  • Initialized buffer
    • can be written to, can be sent
• Consumer
  • Received buffer
    • can only be read

=> Divergence from LoLa, deemed as feasible change

Producer:

• Skeleton
  • Methods
    • Abstract class or handler binding -> handler binding
    • Handler binding part of builder pattern / late binding -> builder pattern
    • Builder enforces at compile time that all methods have handler bound
    • No support for In-Out-Parameters
    • Handler gets references for in-parameters and reference for already allocated result buffer
    • No Poll, no Wait API for now
  • Events
    • Event publication happens through publisher built using builder from Skeleton
      • Allocation API
      • Send API
      • Non-zero-copy Send API
  • Signal
    • Signal triggering happens through notifier built using builder from Skeleton
      • Notify API (no parameters)

Consumer:

• Proxy
  • Methods
    • Method calls follow zero-copy pattern of events (Allocate API)
    • Method invocation happens through invoker built using builder from Proxy
      • Allocation API
      • Invoke API
      • Non-zero-copy Invoke API
  • Events
    • Event polling happens through subscriber built using builder from Proxy
      • GetNewSamples API (non-blocking)
      • Wait API with timeout
  • Signal
    • Signal polling happens through listener built using builder from Proxy
      • Check API non-blocking returns bool (and resets the signal)
      • Wait API with timeout

GAP analysis

Shifted for now:

• Gateway/binding discussion

• Scoped service discovery

• Method support:
  BMW comes up with mock up for methods (C++, Rust)

• API mock-up

  • Branch per language (main_rs, main_cpp)
  • Each language works with PRs on their branch
  • At some point we merge the mock-ups into the main branch
  • C++
    • API mock up except for methods is done on S-CORE side
    • Participants (from workshop participants)
      • Andreas Beetz
      • @timkl7 (potentially)
  • Rust
    • Currently mock up available from Nico Hartmann and Markus Hosch
    • Workshop to align mock ups
    • Participants (from workshop participants)
      • @HartmannNico
      • @MarkSchmitt
      • Markus Hosch