The time tolerance setting in the new SCADAConnect Simulator (and it's associated tools such as Import Initial Settings, calibrator import etc.) is available when editing historical signals in the SCADA Signals dialog, and works as follows.
For SELECTseries 6 and Later
If you specify a tolerance of 5 minutes, then for a requested time of 00:15:00, the time range 00:10:00 to 00:20:00 will be queried. This equates to -5 mins / +5 mins, or 5 minutes before and 5 minutes after. The time tolerance used is -X/+X (for a user specified tolerance of X).
For SELECTseries 5 and Earlier
If you specify a tolerance of 5 minutes, then for a requested time of 00:15:00, the time range 00:10:00 to 00:17:00 will be queried. This equates to -5 mins / +2 mins, or 5 minutes before and 2 minutes after. The time tolerance used is -X/+2 (for a user specified tolerance of X).
The tolerance is applied to the "requested time" which is the hydraulic time (e.g, 1:15:00am, to plot on a graph, or to show in a FlexTable), rather than being applied to the values in the data source.
When we request a value from the data source within a time range, it will read all values from the data source in that range (in this example 1:15:00am - X / + 2.) If more than one value is read, (i.e., if more than one value exists in that time range in the data source) the one closest to the requested time is the one used.
Example for SELECTseries 5
Here is the source data for a test model.
5/14/2015 12:00 AM
5/14/2015 12:05 AM
5/14/2015 12:10 AM
5/14/2015 12:15 AM
5/14/2015 12:20 AM
5/14/2015 12:25 AM
5/14/2015 12:30 AM
If multiple values are found within the specified time tolerance, then SCADAConnect Simulator will show the value that is closest to the actual time as possible. If it does not find a value in the time range then it will show N/A for the value. So if the time range is larger than it needs to be then the value that comes back is not affected in any way (more about this later).
The current best practice with the time tolerance is to set it large enough to ensure that you will always get a value from your data-source, but no larger than that.
Below is the resulting SCADA table after running the test model using a time tolerance of 1 minute (-1/+2) and a time step of 1 minute.
SE-1 - Base - Model Element Value (Numeric) (ft)
SE-1 - Base - Historical Signal Value (Numeric) (ft)
The N/A values are where the time tolerance is not wide enough to find a value (some might not look quite right, like time 26, for example, but that is covered further down).
So for simulation time 2 minutes, our historical time range is:
Start = 2 - 1 = 1 min
Stop = 2 + 2 = 4 min
Query Range = 1 min to 4 mins
Since the source data table contains no values between time 1 min and 4 mins, we get no value back. This is expected.
The way to get data back then is to change the time tolerance to at least 2 mins.
When I do that (change to 2 minutes, I get the following table):
There are still some N/A values because sometimes the time stamps coming in from Excel are not precisely the time that is specified in the data source. For example, time 12:30:00 seems to come through (and is displayed in our SCADA Signals user interface) as 12:29. This may be due to rounding error. Our user interface does not go to the precision of seconds or parts of seconds, but that time is likely 12:29:59 or possibly 12:29:59.999 etc. i.e., some value very close to 12:30:00, but not exactly on it. There is possibly a floating point rounding issue in the Excel data source provider, which is out of our control, but it is not a big deal; more of a cosmetic issue than anything else.
So now if the time tolerance is changed to 121 seconds (for tolerances, increments less than 1 second are not considered), and assuming that the 12:29:59 rounding error above is correct, it should capture all the values properly. (121 seconds is being used here to illustrate the point above, but in practice it is best to just make the time tolerance 5 minutes to be sure all values are picked).
Now everything is working as expected.
The points are shown on this graph, against the actual (test) tank trajectory. The last plotted point seems very much to correlate to the 12:30:00 time as expected.
The above graph shows an apparent discrepancy between the plot of SCADA data and the data table itself. Due to the time tolerance we have specified (let's assume it was 5 mins, but in this example, anything above 121 seconds works) we are able to pick a historical data point for every calculation time, which was run with a hydraulic time step of 1 min. So we see, for example....
Times 0, 1 and 2 have a SCADA value of 0, then at time 3, the SCADA value changes to 1. Similarly, times 8 through 12 have a value of 2, then at time 13 the SCADA value jumps to 3.
One might expect to see this (and all the other data points) plotted on the graph as a step-wise plot using a line to join the points. The reason this does not happen is as follows:
For a simulation time of Y minutes, through the tolerance, we are effectively asking SCADAConnect Simulator for a historical value that is as close to Y minutes as possible, but definitely within a tolerance of +/- X. So in the data table we show the value that we got back, for time Y, however, every value we get back from the SCADA data source is also itself associated with a particular time (time stamp) and so, the value is not necessarily plotted at time Y, but it is plotted at the time that corresponds to the time stamp associated with the SCADA value. That is, we do not change the SCADA data in any way to fit or align it to arbitrary time steps or increments; we simply show it as it really is.
Provided the time scales of the hydraulic simulation and the SCADA data overlap, you will see the SCADA data plotted as it was acquired from the SCADA data source and this allows direct comparisons to be made between simulated data and real data from the field.
In summary, it is best to make the tolerance as wide as it needs to be, maybe plus a little more (the order of minutes), but no wider than that. The risk of making the time tolerance too large is simply performance, since you will always get back values closest to the actual time, but SCADAConnect Simulator will have to search through more values (from a larger time range) before being able to find the best match.
Forum: Time tolerance in Initial Setting Import -tool
Wiki: SCADAConnect Simulator in WaterCAD and WaterGEMS V8i SELECTseries 5