Log In
Home
11/03/2019
Offline
I have a project in hand which requires MQTT publisher to talk to OPCUA nodes and vice versa. I would also like for an MQTT client to be able to use OPCUA service calls e.g. calling a method on an OPCUA node.
OPCUA pubsub allows for MQTT transport. There is a flag in the WriterGroup/ReaderGroup field that can be used to specify the Topic Name for MQTT entities. That would mean OPCUA server application needs to know the transport level details (Topic Name). I don't like specifying anything other than things related OPCUA information model, in the application layer. The application layer should be independent of transport level details. Specifying the Topic Name is like breaking the information model of OPCUA. Moreover, the PubSub plugin doesn't support service call feature.
So, I am thinking of creating a separte Gateway application for communication between OPCUA and MQTT. The gateway would comprise of a OPCUA node and an MQTT client. In addition to this, there will be two topics created by default: "Subscriptions" and "Request". At startup, the opcua node would connect to OPC UA server and complete the browsing request. The MQTT client would publish the browsing response to the Subscriptions topic. Any MQTT client willing to communicate to OPCUA node would have to scan the Subscription for available nodes then make publish or subscribe request using the "Request" topic. The gateway application would take care of the translation of messages; MQTT publish to OPCUA WirteReq and MQTT subscribe to MonitoredItem subscription. OPCUA server and Gateway application-OPCUA node can use the client/server communication or pub/sub as required. If both the communicating parties are assumed to be OPCUA nodes then Topic name can be dervied/standardized from Published_Data_Set(PDS) Name or can be the same.
Thoughts, suggestions, critiscism or anything is welcomed.
05/30/2017
Online
The purpose of the PubSub model is to provide a standard API that allows generic clients to completely configure a publisher or subscriber. This means all information, including details of the transport, must be accessible via this API. Furthermore, the model itself is carefully layered so the same datasets can be easily mapped to different transports depending on the needs of the publisher. IOW, the information model provides the information needed to meet the requirements for which it was designed. I can provide more explanation if there are things about the layering baked into the PubSub model that are are not clear.
The UA PubSub MQTT mapping was developed to eliminate the need for different devs to create custom gateways that can only communicate with software designed with knowledge of that custom gateway. If there are specific problems with the OPC UA MQTT mapping that mean it cannot be used for your application then we should talk about fixing the specification rather than developing ways to work around them.
11/03/2019
Offline
Hmm. My first thought was that pubsub model was only created to avoid individual subscription to each client.
Anyways, as far as I understand the pubsub model, there is no way to invoke a method node using service "Call" and browsing the address space cannot be completed using pubsub. How does the pubsub eliminates the need for a custom gateway application. I can create publishedDataSet having information about the address space but invoking the method node would still remain a problem.
05/30/2017
Online
The PubSub model is the UA mechanism to interface to with brokers and other transports designed to allow a single message to be delivered to many recipients.
This means that the concept of a Call service does not really apply since it relies on a request-response message pattern that does not scale well when used with brokers.
That said there are two possible approaches to implement methods with PubSub depending on what your requirements are:
1) Define a Published DataSet representing a method input parameters. Subscribers would be programmed to invoke the method when the message is received. There would be no direct response, however, Subscribers could publish another DataSet that indicates the result of the method invocation. This would allow a client to invoke a method on multiple servers with a single message.
2) Use sessionless service invocations (see Part 4) to send a JSON encoded call request to a server listening on a MQTT queue. This would require a custom extension to the Server to allow it to listen for the sessionless call requests but this extension would not change the way data is published.
1 Guest(s)
Usage Policy