OPC Studio User's Guide and Reference
OPC UA PubSub Topic Tree
OPC UA specification version 1.05.03 introduced a concept of a standardized topic tree. Topic tree is a well-known addressing scheme for queues or topics, used with message-oriented middleware (such as MQTT). The use of topic tree allows for easier information discovery, because consumer can rely on a certain predictable structure of topics, and can use topic filters to subscribe to subsets of information, without having to known the precise topic names upfront. The topic tree concept, however, does not change the OPC UA PubSub basics, described at other places, at all - it just prescribes a specific use of the general OPC UA PubSub features.
The topic tree organization can be defined separately for different transport mappings. Currently, the OPC UA specification only defines the topic tree for MQTT.
With the topic tree, the topics are organized in the broker in a standard way defined by the OPC UA specification. The component assumes the use of the topic tree automatically, when MQTT transport is used and no individual queue names have been set. In addition, you can enforce the use of the topic tree by setting the AssumeTopicTree Property in the UADataSetSubscriptionDescriptor Class to true.
A topic in OPC UA PubSub MQTT has the following general pattern (the parts in angle brackets are optional under certain circumstances):
prefix/encoding/mqttMessageType/publisherId/[writerGroup[/datasetWriter]]
The first three parts (prefix, encoding and mqttMessageType) are largely taken care of by OPC Studio components automatically, so you do not have to bother with them now. This means that when dealing with OPC UA PubSub system that uses the topic tree, you really just need to be concerned with the remaining three parts, i.e. publisherId, writerGroup (which is actually the writer group name), and dataSetWriter (which is actually the dataset writer name). When subscribing to a specific dataset, you need to specify these parts in the corresponding properties, i.e. PublisherId Property, WriterGroupDescriptor Property and DataSetWriterDescriptor Property. You can, however, also leave any of these properties unfilled, and by doing so, you indicate that you want to receive message regardless of that part. For example, if you specify just the PublisherId Property, message from all writer groups and dataset writers from that publisher will be received.
The prefix part in the topic pattern above is normally always "opcua". This way, applications that produce and consume information in the OPC UA format can do so and will find easily themselves, because all the information they are concerned with can be found in topics that share the well-known "opcua" prefix. A specific OPC system may, howeverm choose to use a different topic prefix. Application in such system then need to be hard-coded ot configured to use such system-specific topic prefix.
If your system uses a topic prefix other than "opcua", you need to set its name using the TopicPrefixHead Property. Using an empty string denotes that any topic prefix is accepted.
Without a topic tree, name of the queue with dataset messages need to be set in the QueueName Property, and the name of the queue with metadata messages in the MetaDataQueueName Property. This is done either from your code, or by resolving the dataset e.g. from the publisher (server). With standardized topic tree, OPC Studio determines the queue names, i.e. the effective values of these properties, automatically, from information such as the publisherId, writerGroup and datasetWriter. You do not therefore have to set the values of the QueueName Property and MetaDataQueueName Property.
For any missing optional piece of information, OPC Studio constructs an MQTT topic filter (using MQTT wildcards) that allows messages with any value for that particular piece be received. For example, if you do not specify the publisherId (using the PublisherId Property), OPC Studio will use a '+' MQTT wildcard at the corresponding position in the topic filter, which tells the broker to subscribe to topics with any string at that position.
Without the topic tree, Message Filtering (OPC UA PubSub) requires that if you specify any filtering requirement, the corresponding information must be contained in the received message, for it to pass the filter criteria. For example, if, without the topic tree, you have specified a writer group name in the WriterGroupDescriptor Property, the actual writer group name must be contained in the received message, otherwise the message will not be delivered to you. So not only will messages with different writer group name be rejected, but the messages that contain no writer group name at all (this is easily possible due to the "optionality" of many fields in OPC UA PubSub messages) will be rejected as well.
With the topic tree, there are cases in which some information is not contained in the message itself, but it can be derived from the name of the topic the message came from (and which the broker provides together with the message). In these cases, OPC Studio components will fill in the information in the message as if it were contained in the message itself, making the filtering possible in a usual way then. In our example, the writerGroup is part of the topic name in the standard MQTT topic tree. If the writer group name is not contained in the received message, OPC Studio will parse the topic name and fill in the writer group name using the writerGroup from the topic name. Consequently, filtering on the writer group name will work as expected.
When topic tree is used, the notion of what are OPC UA PubSub physical identifiers and what are OPC UA PubSub logical identifiers changes. With the topic tree, writer group name and dataset writer name are consider to be physical (and not logical) identifiers, because it is possible to use them directly for subscribing to or filtering the data.
Using the discovery announcement messages, OPC UA publishers can expose information about their status. In adition, with MQTT, the broker can also detect that the publisher has disconnected, and issue a pre-made "last will and testament" (LWT) message to the subscribers. The OPC UA specification allows the publishers can to send their status updates cyclically, or only when the status changes. OPC Studio can deal with all these cases.
When the topic tree is in use, publisher status messages for each publisher have their prescribed place in the topic tree. OPC Studio determines the corresponding topic filter and subscribes to publisher status messages automatically. Any non-operational publisher status is reported as an error through the dataset subscription event handler or callback.