-
Notifications
You must be signed in to change notification settings - Fork 0
Design Considerations
This pages collects design consideration fro the new OPCUA Mqtt Gateway under several Aspects.
This section contains the capabilities of the current OPC UA Cloudpublisher.
It is possible to publish Nodes identified by their NodeId.
It is possible to save/load a configuration of NodeIds that are to published to Mqtt.
The OPC UA Cloud Publisher allready delivers a simple Web-Interface for configuration.
Docker configuration is already done.
That you can connect via the browser to an OPC Server is good. Makes the configuration of Published nodes easier.
This section contains Features that might be interresting to have in a MqttGateway.
In future it might be beneficial to implement a protocol that enables the call of OPC UA Methods and return their ouputarguments as well as the status of the call. It is necessary to implement JobControl and other Method-orientated specifications.
Just not implemented, gateway does not care if types are correct. Maybe an Validator would be beneficial.
There is no way to say I just want to publish Identification like in the old Gateway. Each node has to be published by single selection.
Some CS need to handle dynamic Addressspace changes. There is no way to publish this new nodes.
It will be difficult to debug, cause Mqtt data and metadata is permanenly overwritten with single datasetwriters, so it is hard to get which values are published and which are not in one view.
Fixed strukture, maybe this is ok with the standard, maybe not.
Basically it is a console Application on an IIS Server. Which is a good choice for configuration of a console application.
In my opinion usable, but can be far better. A few bugs. User Interface could be more straight forward and maybe reduced for our purposes.
There are some main problems with the approach as Mqtt Gatewy:
- The selection of published nodes via fixed node Ids will it make impossible to have a general configuration for Machinetypes, cause NodeIds are different in different servers
- Due to the static character of the configuration Addressspace changes can not be addressed correctly
- If the publishing of the dataset stays like it is, it will be very hard to debug. Data is splitted over Topic history.
- Depending if we want to have Method calls over Mqtt we have to implement that.
Another question is if we should allow an configuration of the published nodes via MQtt? I Think it is not our Main concern and we can leave it.
This Section deals with Bugs and instabilities.
This is annoying because the mqtt Adress is stored some where, so it is difficult to change it back.
Error on Pressing the button.
Maybe we can reduce the UI to the things we need.