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

The namespace
urn:SIMATIC.S7-1500.OPC-UA.Application:PLC_OPC_Server
is a PLC internal namesapce. Fortunately it is nowhere refrenced in the model. So one could easily create an empty namespace with the same name before importing the model and the dependency is resolved.
The second namespace
http://www.siemens.com/simatic-s7-opcua
is a self referencing namespace from Siemens and its dependency is gone with the first too.

Thank you Matti

If there is a missing dependency, you will most likely need to contact Siemens for support. If you wish, you can send the NodeSet to us using simulation-server-support@prosysopc.com so that we can confirm the error being a missing dependency.

Do I have to get in touch with Siemens or did someone manage to get a Siemens UPC-UA nodeset running on OPC-UA Simulation Server, may be with a work around?

Regards

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).

> In practice we have not encountered that much “real world examples”
Yes, I guess our usecase is special: we are providing access to dynamically registered devices, kinda "OPCUA as a service" thing. But anyways, “Simple things should be simple, complex things should be possible.” is also valid here 🙂

One more question: You said you don't recommend overwriting SessionServiceHandler - for what reason? It would also be interesting for us to listen and monitor attempts to create (or activate) sessions, as those indicate the number of connections. And it would be good to use the same technique as with the other requests.

Thanks!

I did mean the EndpointServiceRequest version, but as long as you have not used UaServer.getLoopbackClient() (skipping details) then validateRequest(ServiceRequest, ServerSecureChannel) is ok as well.

In practice we have not encountered that much "real world examples". Like, the best one is our public Simulation Server instance which sometimes get "stuck" when someone makes many sessions so that the max sessions/connections limit is reached. But then again normally one has firewall rules that only accepts connections from defined sources, so not sure does even this count.

I will try the proposed approach and let you know, but it looks promising! I just guess you meant `com.prosysopc.ua.server.ServiceHandler.validateRequest(ServiceRequest, ServerSecureChannel)` ?

Regarding the rate limiting, yes, what you say makes sense, but how can an OPC UA server then deal with misconfigured clients and prevent being taken down by an unintended DoS? Do you have any recommendations or experience? I already asked about this in particular in this old thread, but a real-world solution was not found: https://forum.prosysopc.com/fo.....or-server/