For this use case there is neither a 2nd flow (hack) nor a CCS extension by an additional AC property required for the subscriber address (e.g. opc.udp://localhost:4841 for EndpointB).
Because the subscriber address of EndpointB should be included in the SubB of Flow1, see the already released /Part 81/, E.4.4 ‘Unidirectional connection’:

Please avoid the extension of the CCS model for that use case. Please doublecheck and discuss the solution as already fixed in /Part 81/, Annex E.

image.png (180,372 bytes)   

image.png (180,372 bytes)   

I do not miss the subscriber address for endpoint 2. What I do not have is the subscriber address of endpoint 1. This address is not relevant for the actual flow but it is necessary to add/match the PubSubConnection on Endpoint 1.

I think this is related to 0009574

I tried to find the slides I have in mind shown end 2020 for unicast and multicast. But maybe that was discussed in the Part14 team, and the slides are hidden there.

However, the text in Part14 (7.3.2.2 and 7.3.2.3) shows, what was decided back then.

For multicast/broadcast: "All DataSetWriters and DataSetReaders that send to and receive from the multicast IP address shall be configured on one PubSubConnection. The Address parameter for WriterGroup datagram TransportSettings shall be null."
For unicast: "For UDP unicast, the address information for the Subscriber is configured on the PubSubConnection and the address information for the Publisher is configured on the WriterGroup. The receive port for UDP unicast communication is configured on a PubSubConnection. [...] All NetworkMessages for one port are received through one PubSubConnection."
and "The syntax of the Url field in the PubSubConnection Address parameter has the following form: opc.udp://localhost[:<port>]"

That means several PubSubConnections can be configured for the reception of unicast. Thus the easiest in this case would be to add/match the WriterGroup/DataSetWriter for the unidirectional to the PubSubConnection with the reception address "opc.udp://localhost" (meaning 4840 would be used for any reception, if ReaderGroups are added to the connection). If that PubSubConnection does not contain any ReaderGroup, there would be no reception at all, and the reception port has no relevance.

In other words (that is my understanding of Part14), the PubSubConnection's address and port are not relevant for any WriterGroup/DataSetWriter. In fact I could add a unicast WriterGroup to any "localhost" PubSubConnection (if there are mutliple), which matches the required TransportProfileUri and TransportSettings.

Agree with Claudia and Georg above. I think this is already handled with what is specified. For a unidirection, unicast connection, the only information that should be needed is the IP address and receive port of the subscriber. There is no port number on the publisher that is relevant. So the Address in the Flow should be the IP addr:port of the subscriber. And the Address in the SubscriberConfig that is attached to the Flow should be the localhost:port of the subscriber.

Further edit: but there is still the problem, if you don't always use port 4840, how does the configuration tool or CM know which port can safely be used on the Subscriber. At present, there is no way in UA or UAFX to know this. (and this is related to the other Mantis issue that Matthias refers to)

I think you still do not understand my real problem which is a nasty detail of how the PubSubConnection match works. And this is independent of the problem on how to select the right port in general.

For the flow itself, the address on Endpoint 1 is for the WriterGroup (IP and port to send to) and the address on Endpoint 2 is for the PubSubConnection (port to subsribe on). And even if the address on PubSubConnection for Endpoint 1 is not relevant for the flow, I need to specify one when I create the PubSub configuration for Endpoint 1. There is not "do not care" addresss.

I assume the engeneering tool knows the ports of the OPC UA applications. The engeneering tool creates a CCS. I need to know where I can get the port for Endpoint 1 PubSubConnection out of the CCS to create a valid PubSubConnection that can do a add/match on the AC for Endpoint 1.

Sounds like a Part 14 problem :-)

Further edit: in all seriousness now ... looking at Part 14, I guess I do not understand why you need to have the port number for Endpoint 1 at the PubSubConnection level on Endpoint 2, if it is not going to be used. Can't you just use the IP address or host name of Endpoint 1, since the Address in the WriterGroup is going to override what is in the Address at the PubSubConnection level? I don't fully understand why there is an address needed at both levels anyway. I guess at the PubSubConnection it serves as the "default" for the groups underneath, but it can be overriden by those groups? I don't think this is really clearly explained in Part 14 (at least, I could not find it)

Further further edit: I may have my endpoint 1 and 2 mixed up in what I wrote above. It might help if you were to list out, independent of UAFX, what you think the PubSub configuration structures on each endpoint should contain.

At the moment being we do not have any spot, where a OPC UA Server would indicate the ports it is offering for PubSub. We (or better Part14) have to specify such a sport to make it available for engineering tools. If we do not have such a spot, we fall back to the default port, meaning 4840, and at the moment being that might be a problem for Servers which have a problem receiving multicast and unicast on the same port (I recall a discussion some years ago).
An additional problem arises, we we start to use dynamically created ports, since one could not specify the number beforehand at engineering time. For using such dynamic port assignments we would need an addtional handshake to get information about the port (sounds like an extension of the three step approach ...).

My proposal above says, that we (if we do not have any flow back) just take the "default" Unicast PubSubConnection (i.e. "opc.udp://localhost" or "opc.udp.//localhost:4840" - which are the same) for such Writers, where we do not have a receive address configured. There is no need to specify anything in the CCS for that (i.e. no "fake" Subscriber needed).

If a second connection in another CCS has a subscriber defined with another port, we create a second PubSubConnection (e.g. "opc.udp://localhost:9645").

We are mixing different (mantis) issues here - the application specific port selection is not my problem in this Mantis issue. I am in favor of exposing "default" or "valid" ports by the application and I agree this can/must be solved in Part 14 but this is first of all a possible solution for the related issue 0009574).

In my situation, the engineering tool knows the ports of all ACs but has no way to include this information into the CCS (and this is NOT a Part 14 problem). In internal (configuration/engineering tool) configuration structures we (Unified Automation) and Mitsubishi have the default port as a setting/information at the AC level. As long as we create the PubSubConfiguration directly from this configuration, we have no problem to create the PubSubConfiguration for Unidirectional WITHOUT heartbeat. But we found no way to include the AC default port for Endpoint 1 into the CCS.

To create a PubSubConfiguration for Endpoint 1 with UDP unicast requires a port configuration on the PubSubConnection of Endpoint 1, even if no Reader is created.

The selection of a random port, even if not used, is not a valid solution, especially if a device supports only one UDP unicast Port / PubSubConnection and other FX or PubSub applications want to create a Reader later.

My problem would already be solved if we find a way to include the default port for an AC into the CCS. We can easily do this with a KeyValuePairt property in the AC structure in the CCS configuration. But for interoperability reasons I would prefer a solution that is defined by the specification.

In general we designed the Add/Match in combination with ReserveIds in a way, that the complete FX connection establishment can be done with the EstablishConnection Method. The default PublisherId is available as Property on the PubSubConfiguration object but we include into the ReserveIds.

I think we missed the option to include the default port into the ReserveIds response. This would solve the related issue 0009574 and can be also a solution for this issue. At least for FX this could be "extended" without breaking the API. An additional command can be added and the result can be included into the ReserveIds result.

Another attempt could be to add an optional 2nd array element for the SubscriberConfigurations parameter for the Flow of endpoint1 for an unidirectional UAFX connection WITHOUT Heartbeat.
The Flow.SubscriberConfigurations parameter is already specified as an array in the current released /Part81/.
The Address of this 2nd Flow.SubscriberConfigurations array element should be used for the PubSubConnection.Address of endpoint1 (e.g. opc.udp://localhost:48010).
If an optional 2nd array element is not specified for an unidirectional connection without heartbeat the default port 4840 should be used for the PubSubConnection.Address of endpoint1 (opc.udp://localhost:4840).
This solution attempt has the benefit that it is not required to change/extend the CCS model which is compatible with the already specified CCS model and the further benefit is that our already implemented CCS tools can be used without any CCS model changes/extensions.

I honestly also haven't understood the problem up to now. Can we play through the setup of the flow from Endpoint 1 to Endpoint 2 (unicast without heartbeat) using a real (showing the problem) example?

Edit:

I understand that a Connection has to be created on Endpoint 1 (using ElementAdd/ElementMatch) that is required to have an address.
Since the address string in the flow configuration applies to a WriterGroup in the case of UDP Unicasts, a new Connection must be created on Endpoint 1 or an existing one be used.
The address for that Connection needs to be generated and whatever that address is, it will be used for all WriterGroups that do not overwrite the address of the connection.

-> use the address as specified in the flow (this will lead to 1 Connection being created for each UDP Unicast Publisher config) but omit any port (this will reuse Connections to the same target but different dst ports) definition.
-> if a flow address does not specify a dst port, the spec clearly states that the default port is 4840 (which is what I assume a PubSub stack would have to use by default unless a port was configured in the PubSub config model.

I can do a live demo today

In today's discussion, we MUST also consider the OPC UA Ethernet connection. Specifically, what should the default VLAN ID (VID) be in this case?
Reminder:

• The syntax of the URL field in the PubSubConnection Address parameter is as follows:

  opc.udp://localhost[:<port>]

• For OPC UA Ethernet, the syntax of the Ethernet transport protocol URL used in the Address parameter (defined in 6.2.7.3) is as follows:

  opc.eth://<host>[:<VID>[.PCP]]

  Host : This can be a MAC address, an IP address, or a registered name like a hostname. The format of a MAC address is six groups of hexadecimal digits, separated by hyphens (e.g., 01-23-45-67-89-ab). A system may also accept hostnames and/or IP addresses if it provides means to resolve them to a MAC address (e.g., DNS and Reverse-ARP).
  VID: This is the VLAN ID as a number.
  PCP :This is the Priority Code Point as a single-digit number. This optional parameter is typically configured as part of the QoS settings on the network interface and not part of the address.

The transport of a UADP NetworkMessage in an Ethernet II frame is defined in Table 196.

Find this solution attempt as discussion input.
In case of an unidirectional connection without heartbeat Flow2 doesn’t include the optional Address parameter but only SubA which specifies the PubSubConnection.Address of EndpointA.
Figure E.13 – Unidirectional connection without heartbeat illustration:

image-2.png (15,293 bytes)   

image-2.png (15,293 bytes)   

If I can attempt to summarize the conclusions from today's discussion:

• The problem arises because there needs to be a PubSubConnection, with an Address, in order to have a place to put the WriterGroup (for the unicast publisher)
• The Address in the PubSubConnection will be Localhost+ UDP port used for receiving. If the registered port (4840) is used, the port can be omitted. Otherwise the Address will contain a port number in addition to IP addr or host name
• When creating the PubSub configuration, the CM or engineering tool needs to provide information such that the PubSubConnection can be "added" (new) or "matched" (if it already exists) so that the WriterGroup can be attached to the correct PubSubConnection
• There is no way to create a PubSubConnection with a "don't care" Address
• So there needs to be a way for the CM/Engineering tool to know the UDP port that would be used for receiving, so that it can add or match the PubSubConnection

I'm going to repeat my half-joking comment and say again that this really seems like a Part 14 problem to me. If the publisher is only going to do unidirectional (no HB) or autonomous publisher, then there really should be no reason to have to specify a receive port, because it is never going to be receiving. This seems like a flaw in Part 14.

And for the 99% of cases of controllers and devices, I would expect that port 4840 would be used. Before we invent changes to the ReserveIds command (which was talked about), I would ask whether there is a Part 14 change that could be made. E.g., could you make a PubSubConnection with a "don't care" address? And/or could you do an add/match for "localhost" without having to specify a port number?

I suppose we still have the problem from the related Mantis issue, if the application is using a port other than 4840, how does the CM/engineering tool discover that? I would still suggest that is a rare corner case for controllers and devices.

Attached is a proposal to add a FlowProperties definition to F.1.6

The proposal for integration into Part 81 is attached in the last note

We should discuss this before resolving it. I don't think this is a good solution. As noted above, it seems like this is a flaw in Part 14. If a device is not going to be receiving -- i.e., it is a unidirectional publisher, why should there be a need to add a port number for receiving, just so that there is a place to put the writer group? The other problem that remains, even if this were to be used: how does the engineering tool, or whomever creates the PubSub configuration, know which receive port can be used on a server? We know that there is the default port, but beyond that no assumption can be made. If the server is using ports other than the default port then it should be generating those at runtime via the TCP/IP stack. It is bad practice to use port numbers that are registered to another protocol.

Finally, this is proposing a change to appendix F. But what about implementations that are not using appendix F, with either the engineering tool or the CM generating the PubSubConfiguration2 strucure? There needs to be information for what they are supposed to do.

Agreed in call to extend the CCS model to have the keyvaluePair for the communication bucket (and add the key val;ue definition in that section - as well as in the Annex F)