[Additional notes by Jan per Mail]

To be clear, I don’t think this is necessarily a problem that information is replicated, but there are things to be considered.

Generally, this is a chicken and egg problem. What is first:
• Is it first that an engineer decides he wants a multicast data flow and later adds logical connections that would use that flow.
Or
• Is it that end user configured several logical connections, which (intended or by coincidence) have the same attributes, so that the engineering tool decides to put them into a single multicast data flow.

One example when I see potential trouble:

1. Engineer, using his engineering tool designed 2 logical connections with identical communication attributes for publisher (like in the figure below).
2. Engineering tool generated a CCS and PubSub configuration, such that:
   a. CCS contains 2 logical connection each, with its own communication attributes that have identical values for publisher side.
   b. PubSub configuration contains one writer group representing one multicast message.
3. CCS and PubSub configuration are deployed to the CM
4. System integrator connects to the CM with a client and wants to change the publication rate of that multicast stream.
   a. He has to consistently set the publication rate in all instances of attributes that refer to the same multicast message.
   b. Otherwise, if he changed the rate in one place but not in the other places, that would mean there shall no longer be one writer group, but two, each with a different publication rate and effectively 2 multicast streams.

It may be difficult or impossible in the CM to:
• Prevent inconsistent updates by tracking all dependencies between attributes and PubSub elements and enforcing certain attributes to be in sync.
OR
• Handle the inconsistent updates by restructuring (or completely rebuilding) PubSub configuration.

[Additional notes from Jan]

I propose the following draft (see attached file)
It’s kind of restoring the old concept, but improving readability, by adding PublishesTo and SubscribesFrom references, and renaming the CommunicationAttributes to “stream” or ”streamAttributes” (alternative “dataFlow”).

[Remarks by Georg]
However, some comments:
• I would not call them “stream”, since overloaded with TSN terms – maybe misleading
• I like dataflow (I used that some time ago), however, there were some who didn’t like that
• PublishesTo and SubscribesFrom is too PubSub, what about “OutboundFlow” (== publishes) and “InboundFlow” (== subscribes), since that would work also for ClientServer

We should also have a quick discussion, to have some idea (not complete), how the Attributes would work for ClientServer.

discussed in meeting - agreed to implement what is in the slide deck

agreed to HasOutboundFlow and hasInboundFlow (with a parent of HasFlow)
Rename the new object to CommunicationFlowConfiguration

Included in spec as discussed in the team meeting 03/15

Reviewed updated text in call, agreed to text changes and closed issue