The PubSubCommunicationModelConfigurationType defines the communication model-related configuration information for the usage of PubSub as the communication model (see OPC 10000-14).

The PubSubCommunicationModelConfigurationType is illustrated in Figure 48.

Figure 48 – PubSubCommunicationModelConfigurationType illustration

The PubSubCommunicationModelConfigurationType is formally defined in Table 99.

Table 99 – PubSubCommunicationModelConfigurationType definition

Attribute	Value
BrowseName	4:PubSubCommunicationModelConfigurationType
IsAbstract	False
References	NodeClass	BrowseName	DataType	TypeDefinition	Other
Subtype of the 4:CommunicationModelConfigurationType
0:HasComponent	Variable	4:PubSubConfiguration	0:PubSubConfiguration2DataType	0:BaseDataVariableType	M
0:HasComponent	Variable	4:Namespaces	0:String[]	0:BaseDataVariableType	M
0:HasComponent	Variable	4:TranslationTable	4:NodeIdTranslationDataType[]	0:BaseDataVariableType	M
0:HasComponent	Variable	4:ConfigurationReferences	0:PubSubConfigurationRefDataType[]	0:BaseDataVariableType	M
0:HasComponent	Variable	4:ConfigurationValues	0:PubSubConfigurationValueDataType[]	0:BaseDataVariableType	M
ConformanceUnits
UAFX ConnectionManager Base

The PubSubConfiguration modifies the existing PubSub configuration on the addressed Server when establishing Connections. The PubSubConfiguration2DataType is defined in OPC 10000-14.

Namespaces contains namespace URIs for NamespaceIndex used in the PubSubConfiguration. Examples are NodeIds contained in PublishedDataSets. The NamespaceIndex in the PubSubConfiguration will need to be updated to reflect what the NamespaceIndexes are in the addressed Server.

NodeIds contained in the PubSubConfiguration, which use the special namespace “http://opcfoundation.org/UA/FX/CM/Translation/”, are not valid NodeIds but placeholders which shall be resolved before the ConnectionManager can use the PubSubConfiguration for connection establishment. The resolution consists of 2 steps. The first step is done locally within the ConnectionManager, and it involves the conversion of these NodeIds to PortableNodeIdentifiers according to the TranslationTable. The second step involves the resolution of the PortableNodeIdentifiers to actual NodeIds of the Nodes on the target Server (see 13). If a PortableNodeIdentifier is represented by a PortableRelativePath, the starting node of such a path depends on which PubSubConfiguration element the identifier corresponds to. If the identifier corresponds to a published or subscribed Variable (e.g., PublishedVariable of PublishedVariableDataType or TargetNodeId of FieldTargetDataType), the path shall start at the hosting AutomationComponent.

ConfigurationReferences points to elements within the PubSubConfiguration and indicates whether they are to be added, matched, modified, or removed. The PubSubConfigurationRefDataType is defined in OPC 10000-14.

PubSubConfiguration and ConfigurationReferences are generated by the engineering tool creating the ConnectionConfigurationSet or by the ConnectionManager. The relation of configuration elements in PubSubConfiguration to a ConnectionEndpoint is provided by the CommunicationLinks (see 6.12.2).

For examples of how to establish the configuration information for AutomationComponents, see E.2, and for the SKS, see E.5.

The ConfigurationValues Variable contains the names and identifiers that were assigned by EstablishConnections. They correspond to null names or 0 identifiers in the PubSubConfiguration.

OPC UA FX allows multiple ConnectionManagers to establish Connections to a single AutomationComponent independently of each other. It also allows any Client to establish Connections. An AutomationComponent may even receive PubSub configuration (unrelated to OPC UA FX) via corresponding Methods exposed in the PubSub configuration model. Coordinating all possible sources of PubSub configuration can become a very difficult task. Since OPC 10000-14 requires certain elements of the PubSub configuration model to be unique (e.g., WriterGroupId and DataSetWriterId), such scenarios may lead to conflicting PubSub configurations (e.g., identical WriterGroupIds configured by two different ConnectionManagers).

Since the Clients passing in such (potentially conflicting) PubSub configurations are unaware of each other, resolving conflicting configuration elements can only be provided by the entity receiving them. In scenarios where PubSub configuration is generated by a single entity (e.g., an engineering tool), this does not apply since the entity generating PubSub configuration could uniquely determine all names and identifiers.

For certain elements in PubSubConfiguration, the entity generating the ConnectionConfigurationSet may set their names (i.e., PubSubConnection, ReaderGroup, WriterGroup, DataSetReader, DataSetWriter) to a specific value or to null. If set to null, a unique name is generated by the addressed AutomationComponent when passing the PubSubConfiguration using the EstablishConnections SetCommunicationConfigurationCmd. If it has a specific value, that value will be used.

For certain elements in PubSubConfiguration, the entity generating the ConnectionConfigurationSet may set their identifiers (i.e., PublisherId, WriterGroupId, WriterId) to a specific value or to null. If set to null, a unique identifier is generated by the addressed AutomationComponent (see OPC 10000-14). Two options exist:

• The ConnectionManager could apply identifiers (WriterGroupIds, WriterIds) that it reserved on the AutomationComponent with a previously issued EstablishConnections ReserveCommunicationIdsCmd before passing PubSubConfigurations using EstablishConnections SetCommunicationConfigurationCmd. PubSubConnections need specific handling; for details, see additional information in later paragraphs.
• The ConnectionManager could pass the PubSubConfiguration using EstablishConnections SetCommunicationConfigurationCmd with identifiers set to null, allowing the AutomationComponent to generate and assign the identifiers.

It is recommended that the entity generating the ConnectionConfigurationSet uses null Names and identifiers. Additional details for each identifier are provided below. See Annex E.5 for examples.

For PubSubConnections, specific handling applies: OPC 10000-14 requires a PubSubConnection to have a unique Address across all PubSubConnections. This implies that there is exactly one PubSubConnection with a specific Address determining the PublisherId to be used for that Address. It is therefore recommended that the entity generating the ConnectionConfigurationSet sets the names and PublisherIds of PubSubConnections to null and that the ConnectionManager uses ElementAdd and ElementMatch with a null name and a null PublisherId for PubSubConnections. This allows the sharing of existing PubSubConnections. If the PubSubConnection matches, the PublisherId of the matching PubSubConnection shall be used; otherwise, a new PubSubConnection is created with the default PublisherId. The ConnectionManager shall adapt the PubSubConfiguration of subscribing AutomationComponents with the returned PublisherIds as required.

It is recommended to use ElementAdd for WriterGroups and ReaderGroups under the assumption that each ConnectionManager maintains groups separate from other ConnectionManagers.

After a ConnectionConfigurationSet is edited (see 6.7.4), the ConnectionManager shall update the PubSubConfiguration (see Annex E.5 for examples).