Difference between revisions of "OPC UA PubSub Automatic Message Mapping Recognition"

From OPC Labs Knowledge Base
Jump to navigation Jump to search
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
[[Category:OPC UA PubSub]]  
 
[[Category:OPC UA PubSub]]  
 +
= About Message Mappings =
 
OPC UA PubSub uses different message mappings, which define how the PubSub messages are structured and encoded when put into the transport protocol as its payload. Currently, OPC UA PubSub defines two message mappings:
 
OPC UA PubSub uses different message mappings, which define how the PubSub messages are structured and encoded when put into the transport protocol as its payload. Currently, OPC UA PubSub defines two message mappings:
 
* UADP (binary, defined by OPC UA)
 
* UADP (binary, defined by OPC UA)
Line 8: Line 9:
 
The combination of transport protocol and message mapping is described using a ''transport profile URI'', and specified for each OPC UA PubSub connection. For transport profile reference, see [[OPC UA PubSub Transport Profiles]].
 
The combination of transport protocol and message mapping is described using a ''transport profile URI'', and specified for each OPC UA PubSub connection. For transport profile reference, see [[OPC UA PubSub Transport Profiles]].
  
When the transport profile can be safely determined from other PubSub connection information such as the resource address, QuickOPC does not require you to select the transport profile explicitly. For example, if the resource URL start with "opc.udp:", the only available standard transport profile with this scheme is "PubSub UDP UADP", and there is no need to specify the transport profile explicitly. In other cases, however, there are multiple choices possible. For example, if the resource URL starts with "mqtt:", there are two standard transport profiles available wit this scheme: "PubSub MQTT JSON" and "PubSub MQTT UADP". As you can see, in this case it is not possible to unambiguously determine a standard transport profile to be used. QuickOPC will, by default, select the most likely one ("PubSub MQTT JSON", in this case), but it may not be the one you need. In these cases, your application therefore needs to explicitly specify the transport profile, and by doing so, select the message mapping to be used.
+
When the transport profile can be safely determined from other PubSub connection information such as the resource address, QuickOPC does not require you to select the transport profile explicitly. For example, if the resource URL starts with "'''opc.udp:'''", the only available standard transport profile with this scheme is "PubSub UDP UADP", and there is no need to specify the transport profile explicitly. In other cases, however, there are multiple choices possible. For example, if the resource URL starts with "'''mqtt:'''", there are two standard transport profiles available wit this scheme: "PubSub MQTT JSON" and "PubSub MQTT UADP". As you can see, in this case it is not possible to unambiguously determine a standard transport profile to be used. QuickOPC could, by default, select the most likely one ("PubSub MQTT JSON", in this case), but it might not be the one you needed. In these cases, your application would therefore need to explicitly specify the transport profile, and by doing so, select the message mapping to be used.
  
In some scenarios, however, when subscribing to PubSub messages, selecting the precise message mapping is not the ideal solution. For example:
+
= Automatic Message Mapping Recognition =
 +
In some scenarios, when subscribing to PubSub messages, selecting the precise message mapping is not the ideal solution. For example:
 
* You may know that the message mapping may change in the future, and do not want to be affected.
 
* You may know that the message mapping may change in the future, and do not want to be affected.
* You may be subscribing to a larger topic tree, and some of the topics may contain messages published with one message mapping (JSON), and other with a different message mapping (UADP).
+
* You may be subscribing to a larger topic tree, and some of the topics may contain messages published with one message mapping (JSON), and others with a different message mapping (UADP).
 
* You may simply not know what the message mapping is, and want to subscribe without much exploration.
 
* You may simply not know what the message mapping is, and want to subscribe without much exploration.
  
 
QuickOPC offers a way to get around the need to specify the message mapping upfront. It can recognize the message mapping automatically.  
 
QuickOPC offers a way to get around the need to specify the message mapping upfront. It can recognize the message mapping automatically.  
  
Currently, this feature is available with MQTT transport protocol mapping, and it automatically recognizes the JSON and UADP message mappings. Messages in different mappings can be received interchangeably.  
+
Currently, this feature is available with MQTT transport protocol mapping, and it automatically recognizes the JSON and UADP message mappings. Messages in different mappings can be received interchangeably, i.e. each message can have different message mapping.  
  
Internally, this is achieved by using a custom transport profile. The default transport profile with MQTT in QuickOPC is "[[OPC UA PubSub Transport Profiles#MQTT_Subscribe_Auto.2C_Publish_JSON|MQTT Subscribe Auto, Publish JSON]]" (from [[OPC UA PubSub Transport Profiles]]). This profile subscribes to JSON and UADP messages; when used for publishing, it uses JSON.
+
= Custom Transport Profiles =
 +
Internally, the automatic message mapping recognition is achieved by using a custom transport profile. The default transport profile with MQTT in QuickOPC is "[[OPC UA PubSub Transport Profiles#MQTT_Subscribe_Auto.2C_Publish_JSON|MQTT Subscribe Auto, Publish JSON]]" (from [[OPC UA PubSub Transport Profiles]]). This profile subscribes to JSON and UADP messages; when used for publishing, it uses JSON.
  
 
If, for whatever reason, you do not want to use the automatic message mapping recognition, you can always explicitly specify the desired transport profile on the PubSub connection (including the precise message mapping), and it will be used.
 
If, for whatever reason, you do not want to use the automatic message mapping recognition, you can always explicitly specify the desired transport profile on the PubSub connection (including the precise message mapping), and it will be used.

Latest revision as of 14:59, 28 November 2022

About Message Mappings

OPC UA PubSub uses different message mappings, which define how the PubSub messages are structured and encoded when put into the transport protocol as its payload. Currently, OPC UA PubSub defines two message mappings:

  • UADP (binary, defined by OPC UA)
  • JSON (textual, built upon interoperable standard)

With some transport protocols, only a single message mapping is used (or, at least, OPC UA only has a standard profile with a single combination). For example, UDP and Ethernet transport protocol mappings are only used with the UADP message mapping (this is because they are meant for optimized, fast, low-level communications). Other transport protocol mappings, such as AMQP or MQTT, can be combined with different message mappings. For example, MQTT can be used either with UADP or JSON, depending on the needs of the application.

The combination of transport protocol and message mapping is described using a transport profile URI, and specified for each OPC UA PubSub connection. For transport profile reference, see OPC UA PubSub Transport Profiles.

When the transport profile can be safely determined from other PubSub connection information such as the resource address, QuickOPC does not require you to select the transport profile explicitly. For example, if the resource URL starts with "opc.udp:", the only available standard transport profile with this scheme is "PubSub UDP UADP", and there is no need to specify the transport profile explicitly. In other cases, however, there are multiple choices possible. For example, if the resource URL starts with "mqtt:", there are two standard transport profiles available wit this scheme: "PubSub MQTT JSON" and "PubSub MQTT UADP". As you can see, in this case it is not possible to unambiguously determine a standard transport profile to be used. QuickOPC could, by default, select the most likely one ("PubSub MQTT JSON", in this case), but it might not be the one you needed. In these cases, your application would therefore need to explicitly specify the transport profile, and by doing so, select the message mapping to be used.

Automatic Message Mapping Recognition

In some scenarios, when subscribing to PubSub messages, selecting the precise message mapping is not the ideal solution. For example:

  • You may know that the message mapping may change in the future, and do not want to be affected.
  • You may be subscribing to a larger topic tree, and some of the topics may contain messages published with one message mapping (JSON), and others with a different message mapping (UADP).
  • You may simply not know what the message mapping is, and want to subscribe without much exploration.

QuickOPC offers a way to get around the need to specify the message mapping upfront. It can recognize the message mapping automatically.

Currently, this feature is available with MQTT transport protocol mapping, and it automatically recognizes the JSON and UADP message mappings. Messages in different mappings can be received interchangeably, i.e. each message can have different message mapping.

Custom Transport Profiles

Internally, the automatic message mapping recognition is achieved by using a custom transport profile. The default transport profile with MQTT in QuickOPC is "MQTT Subscribe Auto, Publish JSON" (from OPC UA PubSub Transport Profiles). This profile subscribes to JSON and UADP messages; when used for publishing, it uses JSON.

If, for whatever reason, you do not want to use the automatic message mapping recognition, you can always explicitly specify the desired transport profile on the PubSub connection (including the precise message mapping), and it will be used.