Feature Request for IPC

[antonkri]

See Contribution Request Guideline and Feature Request Template.

The IPC feature provides the communication framework in the Score Framework.

Working document see linked pull request

[HartmannNico]

Branch is: hartmannnico-cr-ipc
File is: docs/features/communication/ipc/index.rst

[HartmannNico]

While working on the CR it occurs that "IPC Framework" and "Communication Framework" would need to have the same interface. This also relates to the discussion on Initial Architecture Workshop (https://github.com/orgs/eclipse-score/discussions/3).
Propose to reconsider the naming of "IPC" into "Communication".

[LuNieb]

Are there any expectations for communication configuration tooling ? Also within different scope e.g. Container within different COM stack instance, Partition / ECU level, vehicle level

[LuNieb]

Review Feedback from Conti COM Team:

Additional feature needs:

| Additional Features specification | Configuration and Management: |
Objective: Provide tools and protocols to configure and manage the framework across different environments, ensuring compliance with ASIL-B requirements.
 

| Additional Features specification | Monitoring and Diagnostics Tools: |
 Objective: Enable real-time performance and health monitoring of the communication framework.

 
| Additional Features specification | Quality of Service (QoS):|
 Objective: Define and enforce QoS parameters to ensure efficient and reliable communication.

 
| Additional Features specification | Message oriented communication |
Objectives: The defined information elements are topics, remote procedures and events. With which information elements a data provider could decide to whom the data shall be provided. E.g. for a standard communication case to 'send' any data from A to B it looks like a pub-sub to topics is needed, for which only the consumers can decide to get it or not.

| Additional Features specification | Data representation at user interface and memory |
Objectives: How the user data format (topics, RPC parameters) shall be defined? Via a defined IDL or standard programming language definitions? How the correct user data interpretation is ensured between providers and consumers, when the data are exchanged between different nodes/OS using different architectures, compilers and compiler settings?
Shall the communication framework be responsible for the abstraction of user data (IDL) and the correct interpretation at the user interface? What data representations shall be supported at the user interface and at media level (certain binary encoding, protobuf, markup like json, xml or Autosar encoding, ...)?

| Additional Features specification | Service availability and discovery |
Objectives: The provider un/availability needs to be recognized at the consumers.
Shall service discovery mechanisms be supported?
Shall the service discovery work (full) dynamically, statically (e.g. due to safety requirements) or both?

| Additional Features specification | Supported communication media |
Objectives: Which media beside shared memory shall be supported (e.g. certain OS IPC, hypervisor mechanisms, (virtual) ethernet, PCI, ...

| Additional Features specification | Tracing |
Objectives: For system analysis selective communication tracing support is very useful.
Which trace interfaces shall be supported?
On which granularities communication traces shall be de/activatable?
How minimum runtime impact for communication traces can be reached?

| Additional Features specification | Routing |
Objectives: For other media than shared memory routing is an important topic for IPC, also if the approach shall be extended for node and device communication.
How the routing of data shall be managed?
based on static configurationor dynamically based on service discovery?
p2p links, message brokers, routers or all options selectable?

| Additional Features specification | Kernel support/integration |
Objectives: Shall parts of the IPC solution be integrated into kernel of relevant OS, in order to improve performance and may be security, safe guarding?

| Additional Features specification | Optimization of CPU load and media utilization |
Objectives: Any mechanisms planned to support optimized utilization and CPU consumption for defined traffic in case of high communication throughput, limited resources (CPU, media throughput) and especially the combination

Feedback to actual terms:

**| Infrastructure Elements | **
Endpoints: Endpoints are both the source and the target of every information exchange in teh communication framework. An endpoint providing information is consequently called a provider. With the same logic a consumer is an endpoint consuming information.

ReviewRemark
Provider/consumer definition does not fit to remote procedure only endpoints
Typo 'teh'

| Remote Procedures |
The invocation happens asyncronously. I.e. the invocation of a remote
procedure returns immediately to the invoker.

ReviewRemark
Why synchronous (blocking) RPCs aren't considered as a straight forward alternative. It's an easy to use pattern, if the caller needs to wait for the result(s) or also only for function completion, until it can proceed.

| Remote Procedures & Interfaces & Services |
There is no specific structure defined as an 'Interface' or 'Service'. Instead, an interface as collection of remote procedures can be seen as a collection of remote procedures within a specific namespace that represents the interface.

ReviewRemark
An interface is in my opinion a collection of RPCs, topics and events, not a collection of RPCs only.

| Events |
An event is an information element that communicates the change of a state. An event has no value. The main purpose of an event is to support runtime orchestration.

ReviewRemark
An event has no value. Does this mean, that events cannot transfer any additional data? This could result in a lot of events, because each state transition has to be covered with an own event definition.

| Zero Copy & Data Properties |
Atomic - Access to the data item is an atomic operation. To achieve this the data requires one of two access modes:
Lockfree Access - No thread lock is required to read or write the data. This is the preferred property of zero-copy data.
Mutually Exclusive Access - A thread lock (mutex) is required to access the data.

ReviewRemark
Lockfree access might be reachible for event queues and RPC parameter exchange. But how it shall be reached without special HW support for topics, which are exchanged over shared memory?
Mutually Exclusive Access can be used in same partition, how the access shall be synchronized between virtualized subsystems, especially when running different OS.

[HartmannNico]

Top comment guys! Looking forward to the upcoming discussion.

[HartmannNico]

For the tooling and IDL: we have decided to go with code first and config as code approach. Hence we acknowledge there will be tools and IDL/deployment languages. However those follow the code definitions and are currently not subject of the discussion.