This is a bug in Simulation Server. It has been implemented to use 1000 Values per Nodes as an upper limit, but it seems to be ignoring lower limits provided by Clients.

Also one correction to my first post: Even if I set the numValuesPerNode to 0, I get chunks of 1000 values in the Response. (I thought I had seen one case where it was only one Request/Response, but I'm no more able to get all values at once)

Simulation Server Version is: 2026.1.0-16

I've a question regarding the parameter numValuesPerNode for the historyReadRaw method:

JavaDoc is:
numValuesPerNode - the maximum number of events to return for a single node. If the value is 0, all values between startTime and endTime are returned.

I did some tests using Wireshark to see the HistoryReadRequest/Response calls. I'm requesting history values for one hour from the SimulationServer for one of the Simulation Nodes. So there should be 3600 parameters.

When I set the numValuesPerNode to 0, there is one Request/Response where the response contains as expected the 3600 values.

When I set the numValuesPerNode to 1000, there are four Request/Response where the first 3 response cotains as expected each 1000 values und the 4th the remaining 600.

But then I set the numValuesPerNode to 100, and I would have expected 36 Request/Repsonses, but there are still 4 like when the numValuesPerNode is set to 1000.

So it looks like this:

ReadRawModifiedDetails: ReadRawModifiedDetails
IsReadModified: False
StartTime: Mar 19, 2026 15:00:00.000000000 Mitteleuropäische Zeit
EndTime: Mar 19, 2026 16:00:00.000000000 Mitteleuropäische Zeit
NumValuesPerNode: 100
ReturnBounds: False

HistoryData: ExtensionObject
TypeId: NodeId
EncodingMask: 0x01, has binary body
HistoryData: HistoryData
DataValues: Array of DataValue
ArraySize: 1000
[0]: DataValue
[1]: DataValue
....
[999]: DataValue

So my question, is the numValuesPerNode more or less a suggestion to the server, and the server decides how many nodes it will return?

Thank you

I think the idea is anyways, that with returnBounds=false, you will only get all samples without any interpolation at the bounds. But, you can ask for consecutive time ranges and still get all samples - even the ones that fall on the bounds, but only once.

So now it seems that we are doing the "right thing", but returning the sample at the endTime instead of startTime.

Whereas, for returnBounds=true, the last sample seems to be too much, indeed.

We will need to check this out and see where the flaw is... Thanks for reporting.

I'm just trying to read the history of the 'Counter' simulation value from the Simulation Server and recognized that when I call historyReadRaw with e.g. startDate 03/19/26 14:00:00.0000000 GMT and endData 03/19/26 14:05:00.0000000 GMT and returnBounds=false that I'm getting values from 14:00:01 to 14:05:00.

But as returnBounds was false, I expected values from 14:00:01 to 14:04:59

------------------------------------------------------------------------------------------
historyReadRaw(): startDate: 03/19/26 14:00:00.0000000 GMT
historyReadRaw(): endDate : 03/19/26 14:05:00.0000000 GMT

historyReadAll: nodeId: ns=3;i=1001, indexRange: null, timestampsToReturn: Both, historyReadDetails: ReadRawModifiedDetails [IsReadModified="false", StartTime="03/19/26 14:00:00.0000000 GMT", EndTime="03/19/26 14:05:00.0000000 GMT", NumValuesPerNode="0", ReturnBounds="false"]

historyReadAll: Got StatusCode: GOOD (0x00000000) "The operation succeeded."
historyReadAll: Read complete, returning 300 values

historyReadRaw(): dataValue: DataValue(value=22, statusCode=GOOD (0x00000000) "The operation succeeded.", sourceTimestamp=03/19/26 14:00:01.0000000 GMT, sourcePicoseconds=0, serverTimestamp=03/19/26 14:00:01.0000000 GMT, serverPicoseconds=0)
...
historyReadRaw(): dataValue: DataValue(value=11, statusCode=GOOD (0x00000000) "The operation succeeded.", sourceTimestamp=03/19/26 14:05:00.0000000 GMT, sourcePicoseconds=0, serverTimestamp=03/19/26 14:05:00.0000000 GMT, serverPicoseconds=0)

------------------------------------------------------------------------------------------

I tried the same with returnBounds = true, then I get 302 values from 14:00:00 to 14:05:01 - but I expected the last at 14:05:00

Is this normal or is it one entry too much?

Thank you!

Anyway, now on the nuances and a longer version on the answer.

Based on the SDK method signature used, you create a self-signed certificate. The reality for those is that they are mostly made to practically never expire. Of course this is not ideal, but changing the certificate brings troubles since it needs to be trusted by all apps (again), so in practice most just make them last years. There might be scenarios where the certs are updated, but then just the applications are restarted as it doesn't happen often (lets say, once per a year or two). There the renew flag does allow creating the new certificate, which is probably better than requiring using e.g. openssl to create one or loading an expired one.

OPC UA tries to fix this issue nowadays by introducing a concept called GlobalDiscoveryServer(GDS), that takes care of managing the certificates and trust lists of apps of a "factory floor". There isn't yet a lot support for it out there, things take time; we are also still building support it as well and it probably still takes .. some time, sorry. There are also some unanswered questions, thus more exploration is needed. Though, for self-signed certs, the same issues would happen with each renew, so I can open that a bit.

Since clients need to trust the new certs, ideally I think a server would have endpoints for both the old and new cert at the same time until all parties trust the new cert. If the server just swaps the cert, even if old connections would be kept active, they will eventually need to do a secure channel renew or there is a connection break. At that point depending on the client implementation it is broken until restarted.

Since the assumptions of certs being forever-lasting has been true for like more than 15 years at this point (or that apps just are restarted if the certs are updated), it is unclear can any client application out there deal with this on-the-fly. Also while in some rare cases a server has more than once cert, they have been for different security policies. Now there would be more than one for the same policy. Our own UaClient component for example cannot handle this scenario yet, it will select the first endpoint that is suitable, this happens only on the initial connection, it is never automatically checked again. It might be possible to make it work by nudging it to right direction by calling some methods and/or possibly ensuring certain orderings of endpoints returned by the server (this might be hard at the moment), but the point is that it is not automatic yet.

With GDS and/or CA-signed certs the above only happens if the CA cert itself needs to be renewed. With GDS managing app trust lists, it could resolve this by first updating the new CA to the lists well in advance before it starts to use it for signing. And the CA-signing resolves trust issues since new certs are signed by the CA which then gives already the trust (so dual endpoints would be needed only for certs made with different CA certs, for non-GDS-managed software). Though of course for this world to become reality all apps must then support GDS (or support dual endpoints and better cert selection). Some of this could be done today without GDS, though managing revocation lists is not possible, unless they are transmitted outside of OPC UA means to all apps.

There are some nuances on how a client selects even the endpoint. Of course it might make most sense to choose an already trusted cert that has the most time left until expiry. However, the validation process itself typically drives UI/dialogs to ask the user that is cert trusted if it is not yet. Thus on the other hand it would make sense to choose the latest cert so that it is becomes trusted. However if an UI is running unattended, it might break the app until attended, then it might have made sense to select the older, already trusted (but then there should be another mechanisms for asking trusts from the user; or just only rely on e.g. disk-based configuration).

Once we have GDS support in place, I think then we should support updating it on-the-fly (unless the exploration results that it would never work).

The SDK components are not yet designed for changing certificates. There are a lot more nuances to the matter though, but I'll try to give a larger answer later.

In short, you must restart the UaServer. You might still run into issues regarding the clients, they might also need to be restarted.

Certificate and identity creation - ApplicationIdentity.loadOrCreateCertificate(appDescription, getOrganization(), getPassword(), privatePath, true, hostname);
Setting the identity - UaServer.setApplicationIdentity(identity);

Since there will be clients connected, I am trying to find a way to update the certificate/identity during runtime without a server restart. Is it possible to update the server certificate at runtime in a running UaServer instance? If yes, how? Does setApplicationIdentity() alone update what clients see, or do we need to reinitialize endpoints?

When double values are encoded and decoded, it becomes impossible for Clients to distinguish between null and zero because both use the same encoded form. This also applies when they are used in Structure fields such as Low and High fields of Range. In fact, double is a non-nullable DataType in OPC UA and therefore it is technically not possible to set such values to null. The UI of Simulation Server is simply being misleading as it shows the value without any encoding and decoding and in "Java world" it is possible for the values of these fields to be null.

The OPC UA specification states the following for Range:

If a limit is not known a NaN shall be used. (https://reference.opcfoundatio.....docs/5.6.2)

I've verified that NaN can be used in Simulation Server as the value of the Low and High fields of Range. Thus, you should use that instead of null. Simply type NaN to the text field where you would enter Low and High values and it should be accepted and handled properly by the Server and the Client.

I am reading AnalogItem nodes with EURange properties in my custom OPC UA Client that uses the Prosys OPC UA SDK for Java.

The Range objects from the server have null Low/High values, as shown in the Prosys Simulation Server browser:
https://i.snipboard.io/pASd0y.jpg

In my Java code, I read the Range like this:

In my Java code that looks like this:
```
DataValue dataValue = client.readValue(nodeId);
Object value = dataValue.getValue().getValue();
if (value instanceof Range)
{
Range range = (Range) value;
Double low = range.getLow(); // Returns 0.0, expected null
Double high = range.getHigh(); // Returns 0.0, expected null
}
```
The values being returned by the SDK's Range.getLow() and Range.getHigh() methods are 0.0 instead of null. See debugger screenshot here:
https://i.snipboard.io/wTR8KE.jpg

Interestingly, range.toString() shows Range [Low="0.0", High="0.0"] rather than Range [Low="null", High="null"], confirming the SDK has already converted null to 0.0 during decoding.

My questions:

1. Is this the expected behavior when the server sends null Double values in a Structure?
2. What would be the right way to identify when the Range Low/High values are actually null vs. intentionally set to 0.0?
3. Is there a way to access the raw encoded data or status to detect null fields before the SDK converts them?

We need to distinguish between "no range specified" (null) and "range is 0 to 0" (valid) to properly configure alarm limits on our control points.

SDK Version: 5.4.0-201
Server: Prosys OPC UA Simulation Server

Thanks.
Mithun,
Tridium Inc.

Thanks.

No, we meant on the client side disk.

(Though yes the linked sample happened to be the sampleconsoleserver due to things, but it was meant for a more general point of how to init the store properly, https://documentation.prosysop.....#line.1453 this is the client version, but SDK uses same implementation for both sides)

Client gives that error if it could not find the CA certificate used to sign the server-sent certificate (more specifically, all certs used in the whole signing chain, typically there is 2, CA+Leaf, but could e.g. have 3 RootCA, IntermediateCA, Leaf, or more). You must add it/them so that the client knows it. This can be either done by doing the issuers store and 'PKI/CA/issuers/certs' or for the normal store 'PKI/CA/certs'. Using the issuers store doesn't convey trust to the CA itself, it will only be used for chain validation (and if a revocation list has been added, that as well). Using the normal store causes the client to trust all certs signed by that CA.

This is somewhat due to history because having non-self-signed certs is really rare. If you would have CA-signed certs, then typically one CA is made for a "factory floor" and used to sign all applications (and then one would have that CA cert in the normal store so apps trust eachothers automatically).

SDK 5.5.0 added some initial support for even understanding cert chains, but for now it was mostly for sending one, as far as I remember. Though, even in the future not all servers might send the full chain, even if they use a CA-signed cert.

In most cases you should be able to ask the server maintainer, or if you have access to the machine running the server, typically it would be next to the server's normal certificate file. Or if not, then ask the maintainer to ask the one who created the certificate.

Matti Siponen said
The certificate is part of a certificate chain. You will need to somehow get the rest of the certificates in the chain and put them to issuer certificate store. Most likely this means copying the issuer certificate files to the issuer certificate store folder on the disk.

So by 'copying the issuer certificate files to the issuer certificate store folder on the disk.' you mean on the OpcUa Server, right?

The certificate is part of a certificate chain. You will need to somehow get the rest of the certificates in the chain and put them to issuer certificate store. Most likely this means copying the issuer certificate files to the issuer certificate store folder on the disk.

For an example of defining the issuer certificate store in SampleConsoleServer, see

https://documentation.prosysop.....l#line.698

If you can trust the issuer certificates, you can copy them to the application certificate store instead.

That being said, there might be other problems in the certificate you're attempting to validate on in the issuer certificates, so there could be further steps required after you've provided rest of the chain for validation.