Are there any benefits of one over the other option apart from the possibility to start/stop each individually or together?

The updated SDK is now able to transmit the desired meta-data. As a quick trial I sent the EngineeringUnits as an EUInformation structure and it is easily retrievable from the metadata.

Thank you very much for providing the SDK update so quickly.

Have an enjoyable holiday time.
-HU

Now in the Publisher in com.prosysopc.ua.samples.pubsub.SamplePubSubConfiguration.addPublishedVariableDataSet(Builder, UaNodeId) you can add e.g.
variableConfBuilder.putMetaDataPropertyMap(UaQualifiedName.standard("Test"), "TestValue");
Tested via in Subscriber side in com.prosysopc.ua.pubsub.PubSubSystem.addEventListener if you print the event/metadata.

Note that the SDK doesn't support 'metadata versioning' and it is only created when the PubSubSystem starts. Thus only constant values work. Depending how things go, maybe at some point there could be some "selector" configuration similar to how EventFilter works in opc.tcp events that would select sub-node values from a node being published (and maybe even monitor those ..), but that is possible future exploration.

Also, use namespaces for the UaQualifiedName(s) that are known for both sides. We sort of did a bit of a mistake in the design that both sides are assumed to know the types, but for a generic Subscriber it would instead need a separate "type realm" for each PublisherId+WriterId combination. The DataSetMetaData inherits from DataTypeSchemaHeader (from which also UABinaryFileDataType inherits) that is intended to list types used by the Publisher (though, in a case where the data would get pushed to a node on the server, then it must also follow that the server must know the type, or there wouldn't be much sense as far as I can think of use-cases).

Basically there is almost no information modelling in the PubSub side.

The metadata SamplePubSubConfiguration is related to which MQTT Broker topic the DataSetMetaData is published. You might be referring to the FieldMetaData https://reference.opcfoundatio...../6.2.3.2.4 that is contained in the DataSetMetaData. Currently there is no way in the SDK to cause anything be sent in the 'Properties' field related to it.

In UDP the Subscriber must ask for the metadata via the multicast network, the Publisher would then send a message that contains the DataSetMetaData. It would seem the spec also nowadays allows cyclic publishing (we could implement this in the future).

The only info our SDK Subscriber side would currently look from the DataSetMetaData are the field names. Custom types are not supported (but will probably work, if the Subscriber side already knows them) nor is the RAWDATA mode. Our Subscriber side will invent Field#### style names for fields of datasets for which it doesn't know the metadata. It will also send the "discovery request" messages for which our Publisher side will respond with the DataSetMetaData messages.

The received metadatas will cause SDK to update the PubSubSystemConf of the PubSubSystem. They can also be manually set via PubSubSystemConf.Builder.addDataSetMetaDatas(PubSubDataSetMetaDataConf). This only works for the Subscriber side, not for the Publisher side. The idea at least was that the SDK calculates the metadata from the nodes, as they already contain the information.

The com.prosysopc.ua.samples.pubsub.SampleUtils.addPubSubSystemListeners(PubSubSystem) shows how to listen for DataSet and DataSetMetaData messages. The metadata can be obtained also from PubSubDataSetMessage.getDataSetMetaData(), assuming it is known.

P.S.
The PubSubSystemConf PubSubDataSetMetaDataConf is only used in the Subscriber side.

PubSubPublishedVariableConf.getMetaDataPropertyMap() I believe at the moment does nothing. Probably should be categorized as a missing feature or bug, some of the thing were originally added 1:1 mirroring the spec configuration. It probably should go to com.prosysopc.ua.pubsub.PubSubFieldMetaDataConf.getProperties(), then I think it might get sent.

P.S.2
Vacation season starts soon, thus it might take after summer to do much

P.S.3
If a Subscriber would need instead a .uabinaryfile for the publisher configuration (this used to be common), there is a prototype implementation via PubSubSystem.commands().execute(PubSubSystemCommands.INTERNAL_PUB_SUB_SYSTEM_CONF_TO_UABINARYFILE, command) and give PubSubSystemConfToUaBinaryFileCommand as the command. Then com.prosysopc.ua.UaBinaryFile.toBinary() and write the ByteString.getValue byte[] to a file.

Could you please provide a short example of adding meta-data on the publisher side and retrieving it on the subscriber side? Both sides would be servers as well.

Many thanks

PS: I tried using PubSubPublishedVariableConf.putMetaDataPropertyMap` and `PubSubSystemConf.addDataSetMetaData'. But neither seems to serialize the meta data on the wire

Sorry, not supported by the SDK.

It might be implementable in the application level. However, some notes might be of use. To begin with, it would need to be differentiated do we talk about the ... "complicated hierarchical version" or "single FileType node version" of the address space. Also the use-case would need more details.

Seems nowadays the spec actually has an official "single FileType way" https://reference.opcfoundatio.....14/9.1.3.7. Something like this was typically seen as a custom solution when PubSub came out. Implementing the original information model is complicated, not sure has anyone done that. And if has, then does anything actually use it. For example, UaExpert back then had PubSub configuration view just writing a UABinaryFile to a custom FileType node. Lets just say PubSub is more "work-in-progress" than 'opc.tcp' (in general and our SDK-wise).

Probably the FileType way (PubSubConfigurationType) is a lot easier to implement in an application and since it is also atomic swap it probably would be the way to go for tools. Though, it is harder to visualize, as it needs to be read first.

PubSubConfigurationType might be implementable using SDK 5.7.0 by implementing custom FileTypeNode.FileWrapper + FileTypeNode.RandomAccessFileWrapper. You will also need to set an implementation of the com.prosysopc.ua.types.opcua.server.PubSubConfigurationTypeNodeBase.setCloseAndUpdateMethodImplementation(PubSubConfigurationTypeCloseAndUpdateMethod) as the PubSubConfigurationType methods are not implemented in the SDK. This could be something we could maybe implement in the SDK itself, though unlikely to happen "exactly now", maybe after summer.

For the "complicated hierarchical version" I can mention that UaServer.setPubSubConfigurator(PubSubConfigurator) was originally created as a hook for all the Method calls related to PubSub (https://documentation.prosysop.....rator.html, there is a lot, Codegen creates code that handles the routing to this interface). Though, in addition one would need to handle other services as well such as some Writes. Maybe this model could better serve as a read-only variation and possibly for e.g. restarting a failed Writer or something like that (as that is not a configuration change, sort of).

One of the downsides of us going with our own configuration style com.prosysopc.ua.pubsub.PubSubSystemConf, is that you need to convert it to com.prosysopc.ua.stack.core.PubSubConfiguration2DataType and back. SDK does not yet offer a method for this. Skipping details.

com.prosysopc.ua.UaBinaryFile offers some support for com.prosysopc.ua.stack.core.UABinaryFileDataType. Skipping a lot of details about custom types.

I am undertaking my first steps using the Prosys SDK for PubSub (UDP Binary). One benefit of an OPC UA server used for pubsub, as advertised by the OPC UA standard, is the ability to configure pubsub via the Server/PublishSubscribe part of the Server addressSpace.

Is there any support for this built-in to the SDK? I created a publisher as per pubsub tutorial and samplepublishserver, yet the addressSpace does not reflect anything of that configuration. Is there any automatic synchronization in either direction between the server addressSpace and the effective pubsub configuration or is this to be managed in application code?

Many thanks, Hans-Uwe

Let me reformulate my "wish" for an ideal code generator:
Assuming a / any valid nodeset.xml as an input, the generated code should be compileable without errors and expose all features of the nodeset design. I am very aware that this presents a real challenge and that this is hardly - if at all- ever accomplishable. So this is not any criticism - just a Christmas wish 🙂

As far as I'm aware, AccessLevel in the InstanceDeclarations is more like a "default value", not a "contract". At least based on the base spec I mean. A companion spec might be able to limit this (in the text, not in a way for Codegen to know). Some Attributes have limits, https://reference.opcfoundatio.....00-3/6.2.7 + https://reference.opcfoundatio.....00-3/6.2.8, but to my knowledge nothing is said for AccessLevel. Also, the generated setters are mostly for server side, but there it is usable always for setting the value, even if it would be read-only from a client's point of view.

Just be careful to remove the component-setter version from all of the generated files (i.e. not accidentally removing the method one in e.g. one file). The method one does also have ServiceException in addition to the StatusException. Note that the only difference to the Codegen-InstanceDeclaration-exclusion-way is that the getter and "node-getter" generated methods exist still (but this could be important).

P.S.
This of course causes me to think could we have some day an option to exclude "any generated method". We do have class-level exclusions https://documentation.prosysop.....ut-classes, basically to avoid generating XXXTypeNodes that are in version control due to implemented methods.

Though it would still be more of a workaround than an actual solution.

I am reluctant to exclude anything from code generation because most of the variables/components/methods are indeed important and required.
While the nodeset design is a bit unfortunate from a code generation perspective, it is still quite common to use explicit UA methods as setters and have likewise named read-only variables. It would be "cool" if some time in the future the code generator could consider the accesslevel of a variable.as well. if it is "CurrentRead", then not generate a setter, if it is CurrentWrite and a setter method exists as well, then emit a warning.

I created (or rather Github Copilot) a gradle task to analyze the generated code, looking for setter and method definitions with conflicting signatures and remove just the duplicate setters. This way I don't need to exclude any components and the code is compiling okay.

Once again, many thanks for looking into this.

It is a known issue: https://documentation.prosysop.....own-issues

The model https://reference.opcfoundatio.....0020/6.6.3 defines both a CalculatedPosition component and a SetCalculatedPosition Method. Thus it will conflict when we create the setter for the CalculatedPosition component and then the actual method for calling the Method. Codegen is not yet smart enough that it would detect and report this as an error directly. (There are also few other types in this model that do the same); we can hopefully do this at some point.

You must exclude one of them via https://documentation.prosysop.....generation. I would recommend excluding the CalculatedPosition component, as it is easier to get via the generic UaNode.getComponent(QualifiedName) than implementing the Method call via https://documentation.prosysop.....tener.html style.

Thus, something like this in the Codegen configuration should do it:

(...some day better code-snippet way.... but anyway have "http://opcfoundation.org/UA/MDIS:CalculatedPosition" without quotes as the 'instanceDeclaration' tag data)
Note that it does exclude the CalculatedPosition node from all types of http://opcfoundation.org/UA/MDIS. This was originally designed to avoid conflicts with the SDK API itself.

P.S.
Personally I would say it is a bit of an odd choice in the model that there seems to be Methods that just serves the same role as what a simple Write operation could do. There is maybe a bit of nuances regarding the async clause https://reference.opcfoundatio.....0020/6.6.7 though Write does have that as well https://reference.opcfoundatio.....4/5.11.4.4. (though only in the presence of an "intermediate system", though an UA Client doesn't anyway know nothing of that so.. why does it matter). However, this is not the first time we see such models, so it is probably too late anyway to try to change them. Also, there could be valid cases, if more parameters would be involved the very least. (Or there could be something I miss here).

P.S.2.
It is possible we some day do something for this. Though it is .. somewhat complicated to find a good solution that doesn't involve excluding. We could e.g. start to use prefixes for methods i.e. 'callXXX' instead of 'xXX' where XXX is the method name (though this would change all existing ones). It could maybe be a flag in the Codegen configuration, though then it gets tricky with overriding of methods (even more if doing so from the core model that is already generated in the SDK). We could try doing that only for methods starting with 'set'/'get', but then it is different based on the name (and could still maybe theoretically conflict). We could add a unused parameter as the first java-parameter in the method, but that too is a bit clunky solution.

I would like to generate code from the MDIS Companion standard, v1.3. The code generation itself succeeds without warnings or errors. The code does not compile, though, because some method declarations occur twice within the same class or interface.

Is this a problem with/of the companion standard or does the code generator need to be configured in a custom way?

As an example:

Edit: Taking a closer look at the nodeset / companion standard, there is a read-only variable for each method, reflecting the value, which the method is expected to set. It looks like the code generator creates a setter method for those variables nonetheless. Another indicator for this are the declared exception types.
Is there any way to configure the code generator to NOT generate setters for any variable at all?

Define 'isolation' and 'user'.

Some levels of 'isolation' is impossible, as the network and execution environment is shared. For example, the message processing does use a shared thread pool (but even if not, individual threads would share the CPU). You would need a separate server per user and different hardware or container execution limits to avoid that. (Then you could use https://prosysopc.com/products.....-ua-forge/ to aggregate them to create an "admin view" server).

For 'user' are we talking about your customers (i.e. "your users") or an OPC UA 'User'. Note that the UA User is only known at ActivateSession, before that you do not know it, thus you can only have "global limits". Non-UA-users would then be e.g. IP-ranges (socket connection), ApplicationUris (client certificates, UA Applications, OpenSecureChannel) or ApplicationDescription (CreateSession, has more detail than just ApplicationUri, though not much more). Personally I would say socket-level limitations should be done on the firewall already, maybe we some-day have things in the SDK, but at the moment it is not possible to limit on that level (other than the global limit).

There is a thing UaServer.setOperationLimits(OperationLimits) (set before UaServer.init()), that does control how many operations a ServiceRequest can contain. Default is 10000 in each type. This is also global though. And assuming relatively normal hardware I would keep it at 10000. One reason is that our client side by default does Read/Browse the entire Types part of the address space on connect (skipping some details, but mostly for Structure metadata; not ideal, but I would say best option so far). It doesn't typically result in that many individual ServiceRequests, but the total number of operations of them might be in 10000-30000 range total.

P.S.
This forum will most likely be down for a few hours later today due to infrastructure changes.

Bjarne Boström said
SDK already limits sessions and connections.

Yes, but those limits are global and not user-specific, right? As I said, we have a multi-tenant service (OPCUA as a service), where users should be isolated from each other and handled individually.

The SessionServiceHandler lacks the protected xxx(ServiceContext serviceContext, XXXRequest request, XXXResponse response) methods what are in the others. It goes more directly to the SessionManager. In the others they are sort of a "last effort place" to try to implement something, but regarding sessions SDK already should be implementing it .. completely (compared to e.g. data related to a Node's Attributes).

We do have intended ways for this as well: UaServer.getSessionManager().addListener(SessionManagerListener) see https://documentation.prosysop.....tener.html. Also, for just user-validation there is UaServer.setUserValidator(UserValidator).

We have also build ways to override the SessionManager via a subtype, similar to the handlers, though the raw ServiceRequest is not available (but the relevant parameters of it are, in the protected methods). It is also possible to use a subtyped Session.

Note that SDK already limits sessions and connections. They are separate things, though most of the time it is 1:1. By default SessionManager.getMaxSessionCount() defines max number of sessions and by default 10% more (at least +1) opc.tcp connections can be made. This so that a client can see that the server is at session limit. UaServer.setMaxOpcTcpConnections(Integer) can be used to set a different limit. Note that in the SDK (and per UA spec), non-properly-ActivateSession'd connections are dropped if at connection limit and a new one arrives. Note that there is not a way to observe the actual connections (we might build this some day).