Matti Siponen said
Hello,

Method Nodes do not have AccessLevel and UserAccessLevel Attributes. Are you referring to Executable and UserExecutable Attributes?

Regardless, Simulation Server doesn't currently allow setting values for AccessLevel and UserAccessLevel Attributes of Variables or Executable and UserExecutable Attributes of Methods.  

Thank you. Would it be possible to request the access control feature for the sim server.

Method Nodes do not have AccessLevel and UserAccessLevel Attributes. Are you referring to Executable and UserExecutable Attributes?

Regardless, Simulation Server doesn't currently allow setting values for AccessLevel and UserAccessLevel Attributes of Variables or Executable and UserExecutable Attributes of Methods.

I am able to add methods in the Object tab to a folder, but I am not unable to add or set attributes like 'AccessLevel' or 'UserAccessLevel' to allow only authorized calls on the method nodes.
Is attributes for methods specified in the protocol?
If so, is this supported by the implementation?
If not, is there a recommended workaround to achieve this?

Thank you!
Mithun,
Tridium Inc.

The certificate and the private key of Simulation Server were updated in version 5.3.0 (see https://downloads.prosysopc.co.....sion-5-3-0). Therefore, updating from 5.0.4 to 5.6.0 would also cause the application to switch its certificate. Please, make sure the the LDS trusts the new certificate and try again.

Which Server did you update and from which version? Can you provide more information on the Local Discovery Server you're using?

Product: Prosys OPC UA Simulation Server
Version: v5.6.0‑6
SDK: Prosys OPC UA SDK for Java 5.4.0‑201
License: Free license
Operating System: Windows (64‑bit)

During discovery registration, the server initially attempts to register using opc.tcp://localhost:4840, but the OPC UA stack automatically switches to an alternate endpoint URL using the machine’s fully qualified domain name (for example, opc.tcp://:4840). Despite successful TCP connections and completed handshakes, the discovery server immediately closes the connection, and the registration never persists.

Could someone let me know what's going wrong here? Everything used to work in the previous version of the server. I am seeing the issue after the server version upgrade.

Here is the details from the server log:

02/26/2026 16:11:24.898 INFO [DiscoveryRegistrationTimer] - localhost/127.0.0.1:4840 Connecting
02/26/2026 16:11:24.908 INFO [DiscoveryRegistrationTimer] - Connected (non-reverse), handshake completed
02/26/2026 16:11:25.126 INFO [DiscoveryRegistrationTimer] - 11 Closed
02/26/2026 16:11:25.126 INFO [TcpConnection/Read] - localhost/127.0.0.1:4840 Closed (graceful)

...

02/26/2026 16:11:26.392 INFO [DiscoveryRegistrationTimer]
Using an alternate endpoint URL
'opc.tcp://bgl7115win64.mathworks.com:4840'
instead of the requested 'opc.tcp://localhost:4840'

...

02/26/2026 16:21:27.183 WARN [TcpConnection/Read]
Bad_SecureChannelIdInvalid (0x80220000)
"The specified secure channel is no longer valid."

...

02/26/2026 16:56:26.442 ERROR
Failed to renew security token.
Bad_ServerNotConnected (0x800D0000)

Maybe we can some day add a flag when creating the node or provide additional attribute simulation or configurability, though not sure when or if this happens (you would need to talk with sales@prosysopc.com)

So if having static data would be enough then that loading via a nodeset is a workaround, though loading such amount of nodes could take hours depending on the distribution of types and instances etc. (in short inside the SDK if 'UaNodes' are being used then adding a new reference does check all references of that node first, types do have a reference to the instances of them). This would require creating such nodesets though. We have some future stuff https://prosysopc.com/blog/pla.....on-server/, that might make it easier to try to duplicate a server (though exporting this amount of nodes might be hard, memory might run out first). Also I should note that the playback feature itself most likely cannot scale to a very high node count. Anyway, if you wish to test, ask sales@prosysopc.com.

However, since you do have the SDK, it might be just easier to try to build something on top of the SampleConsoleServer. For node amounts of this many I would recommend going with the 'MyBigNodeManager' example route, though it should be noted that instances and references here must be modelled manually (i.e. it is more like a view to some existing data(base)).

Thank you for the reply. Yes I have the Pro license.
Yes I am able to add the duplicate points, the performance degrade is not an issue and in fact the purpose of my exercise. We are trying to benchmark and debug performance issues for our application that uses the Java SDK. Our customers in the field have points (around 160k) that do not have history and they also do not have history.
We want to simulate these conditions as closely as possible in the Simulation Server, and hence I want to disable the historizing for the points. Even constant points do have the history.

Can you clarify why you want them without history? In short that is not possible.
For nodes other than Constant Value Type simulation the history is also simulated on-demand, it doesn't take memory. For Constant nodes (yes the name is maybe not ideal) it does store some amount of the real values if written by a client.

That being said, there is no easy way to add 200k nodes. It should be noted that you most likely end up having performance problems long before reaching that point, but depending on the machine and patience one way to try is having the Pro license and loading a nodeset with that many nodes.

Other than that there is an option in the right-click menu to duplicate a node, though that is intentionally limited to 4999 due to performance constraints. Though, you can add duplicate node inside a folder, and then duplicate the folder itself, possibly also cut-pasting the folder as a subfolder and continue.

Please note that saving the project can take a _very_ long time with higher node counts depending on the machine.

Thank you,
Mithun Tiruvedula,
Tridium Inc.

Can you please clarify what you mean by an "answering address"?

You could possibly mean the "EndpointUrl" that is returned in the EndpointDescriptions e.g. during CreateSession service call. Assuming so, our take on that has been that it basically serve no purpose and should be ignored. Clients should use the original connection address they used in the first place, this allows them to e.g. work in environments where the server is behind a NAT.

There is no intended way to configure it, hostnames have been de facto thing to used in EndpointUrls for like the past 15-20 years.
It should be noted that in our implementation at least it doesn't mean anything vs. what network interfaces are being listened to: by default they are all listened via ip wildcard.

Though, it should be noted that we try to resolve the FQN version of the hostname. So, if you configure your hosts file such that a reverse-dns (because that is how it works in java) would produce an IP address, it might appear there. Or if you somehow make it so that the hostname is already an IP address it might as well, though these should be considered as tricks, not intended ways.

It seems like something has corrupted your Simulation Server configuration to the point where opening the application won't work. Unfortunately there is nothing else that can be done except deleting the existing configuration located in [userhome]\.prosysopc\prosys-opc-ua-simulation-server where [userhome] is your userhome, which on Windows is C:\Users\[username] where [username] is your username. You should be able to keep log, PKI and USERS_PKI folders and license.lic and log4j2.xml files but everything else should be deleted to start using Simulation Server with a new configuration.

Also, you're using an older version of Simulation Server. The newest version adds project management, which enables saving the Simulation Server configuration to file and loading configurations from files. We would recommend updating to the newest version as project management would enable creating back ups of the configuration that you could load if the configuration somehow becomes corrupted.