OPC UA Pubsub over MQTT|OPC UA Standard|Forum|OPC Foundation

Avatar
Search
Forum Scope


Match



Forum Options



Minimum search word length is 3 characters - maximum search word length is 84 characters
Lost password?
sp_Feed sp_PrintTopic sp_TopicIcon
OPC UA Pubsub over MQTT
Avatar
John Dough
Member
Members
Forum Posts: 4
Member Since:
04/08/2021
sp_UserOfflineSmall Offline
1
05/27/2021 - 01:47
sp_Permalink sp_Print

Hello all,

 

I have been reading through the OPC UA Reference (v104), specifically Part 14: PubSub under PubSub Concepts. I would like to verify if my understanding is correct.

1. An information source is usually the publisher (Can be a logical node, a physical sensor, or some sort of OPC UA Server)

2. The subscriber is the consumer of information

3. The flow of information is one way: Publisher to Broker to Subscriber

4. The spec does not specify that the publisher should have to handle any actions/ methods/ services from the subscriber (also to say, making it a "two way" connection)

 

Thank you.

Avatar
Randy Armstrong
Admin
Forum Posts: 1451
Member Since:
05/30/2017
sp_UserOfflineSmall Offline
2
05/27/2021 - 04:35
sp_Permalink sp_Print

request-response operations are provided by UA client-server. Numerous technical issues make it problematic to replicate this message pattern over a broker designed for large numbers of devices.

A publisher can also be a subscriber so two way communication is possible - just not a formal request-response message pattern.

Avatar
John Dough
Member
Members
Forum Posts: 4
Member Since:
04/08/2021
sp_UserOfflineSmall Offline
3
05/27/2021 - 21:46
sp_Permalink sp_Print sp_EditHistory

Randy Armstrong said
request-response operations are provided by UA client-server. Numerous technical issues make it problematic to replicate this message pattern over a broker designed for large numbers of devices.

A publisher can also be a subscriber so two way communication is possible - just not a formal request-response message pattern.

  

Hi Randy

 

I was having the same qualms regarding implementing the request-response pattern over a broker too. With regards to the last sentence, does that mean the spec only specifies data and event transfer over pubsub, but not method invocations (as this require two way communication, which the spec does not specify either).

 

Thank you.

Avatar
Randy Armstrong
Admin
Forum Posts: 1451
Member Since:
05/30/2017
sp_UserOfflineSmall Offline
4
05/28/2021 - 00:29
sp_Permalink sp_Print sp_EditHistory

A method is just a set of input parameters and a set of output parameters so you could design 2 datasets to look like a method.

The important point to keep in mind is you can only have "methods" where the caller is not expecting to block waiting for a response. Ideally you would want methods that can be sent to multiple responses can be sent without breaking the pattern.

For example, in electrical distribution you could have a centralized service send a "ShedLoad" command and every device that receives would return a ShedLoad response indicating whether it could do it.

In other cases, it would make no sense to use pubsub to implement a method. For example, a method to browse the file system on a device would implicitly require the caller to make multiple calls in sequence based on the results returned. This kind of thing is best done with client-server.

Avatar
Randy Armstrong
Admin
Forum Posts: 1451
Member Since:
05/30/2017
sp_UserOfflineSmall Offline
Forum Timezone: America/Phoenix
Most Users Ever Online: 510
Currently Online:
Guest(s) 16
Currently Browsing this Page:
1 Guest(s)
Top Posters:
Forum Stats:
Groups: 2
Forums: 10
Topics: 1349
Posts: 4577