Hi,

We do not yet have any version that would include any pubsub support. We are working on that (lets just say the number of support cases and other required fixes has been a lot bigger than estimated originally so less time for development). Probably at least some kind of beta (might not be public) version within early Q2 of this year. Note that first versions will not support everything. Therefore just saying “Pub/Sub” is not enough, since that means a lots of different things (UADP+UDP, MQTT, AMQP, binary or json encodings, is security needed? etc.). But e.g. for UADP+UDP we are quite close for making a beta release.

We do not have any examples for those redundancy facets. However are you yourself familiar what those actually means? We use the terms from the specification profiles, however what they actually mean might not be what you are thinking.

e.g. https://reference.opcfoundation.org/v104/Core/docs/Part7/6.6.116/, defines Redundant Client Facet. That means that the only thing that must be supported is the conformance unit “Redundancy Client”. And well, it is optional to support “Subscription Client TransferSubscriptions” (we support TransferSubscriptions).

However, “Redundancy Client” only just means (per https://apps.opcfoundation.org/ProfileReporting-v1.02/index.htm?ModifyProfile.aspx?ProfileID=c942a19b-8615-4c84-a81c-a20e26eec062) “Client supports Client redundancy. Clients that support Client redundancy can failover to another Client (requires some out of band communication).”. Since our SDK allows you to make more than one OPC UA Client, this is possible.. But it is upto you as an application level designer to come up with some kind of out of band communication way that the client knows that another client has failed for your specific use-case.

We will eventually make some examples, but priority for making those is not very high at the moment. Lets see once pubsub is done…..

I wont go into details, but if you read Part 14 you will see that a large part of the functionality is common for all of the “PubSub protocols”. Thus it will be relatively easy to add the rest of them once we have one of them.

There are multiple different modes there in the Table 111 (Failover mode and Client options Cold Warm Hot (a) Hot (b) HotAndMirrored). Generally redundancy depends entirely on what kind of scenarios do you have in mind? Is data loss ok? Is any delay of getting data ok? Is there a bandwidth limit in the network? Is there CPU+RAM limitations to run multiple clients/servers? Does your server support History for data and/or events? Do you control all clients and/or servers? What is the original source of the data? Does that need to also be mirrored etc?

P.S.
Generally speaking application development is outside of the technical support.