This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Time tolerance in Initial Setting Import -tool

Hello,

I'm testing the Initial Settings Import -tool in SCADAConnect simulator. I have the metering results of tank level from every 15 minutes (Excel) and I have made a SCADA Signal connection to the data. I'm using time tolerance of 5 minutes.

I tried to test how the 5 min time tolerance works by trying to import tank level value from time 00:15:00. If I have understood time tolerance right, I should get that value imported with Import Options (historical) being something between 00:10:00 - 00:20:00. However, the import only succeeds with a time between 00:13:00 - 00:20:00 (2 min before and 5 min after). The same thing happens with other metering times (00:30:00, 00:45:00 etc.) too. Why does the time tolerance function differently before and after the selected import time?

Regards,

Ulla K.

  • EDIT: To correct some minor details and improve the wording in some areas.

    Hi Ulla,

    The time tolerance setting in the new SCADAConnect Simulator (and it's associated tools such as initial conditions import, calibrator import etc) is currently working as follows.

    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.

    It was set up this way so that the time tolerance is effectively looking into the past, by whatever amount is specified by the user. The 2 minute look ahead range is currently fixed and was set that way primarily to deal with reading real-time values (mainly to ensure that PC clock out of sync issues were handled), however, we during development we changed the way things work and real-time signals did not end up making any use of the time tolerance (which is why it is disabled if you specify your data source to be real-time), so perhaps it might be more appropriate for us to change that and use the same time tolerance specified by the user for looking ahead too, instead of the currently fixed 2 minutes. i.e., make it so that the time tolerance used is -X/+X (for a user specified tolerance of X).

    It is probably worth me mentioning that 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 (I will mention a little 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.

    In the meantime I created a test, with  the following source data:

    Date/Time Stamp Signal Value
    5/14/2015 12:00 AM 0
    5/14/2015 12:05 AM 1
    5/14/2015 12:10 AM 2
    5/14/2015 12:15 AM 3
    5/14/2015 12:20 AM 4
    5/14/2015 12:25 AM 5
    5/14/2015 12:30 AM 6

    The using a time tolerance of 1 minute (so in practice -1/+2) then when I run my test model with a time step of 1 minute and plot the SCADA data I see this table.

    Time (min) SE-1 - Base - Model Element Value (Numeric) (ft) SE-1 - Base - Historical Signal Value (Numeric) (ft)
    0 1 0
    1 1.17 0
    2 1.34 (N/A)
    3 1.51 1
    4 1.68 1
    5 1.85 1
    6 2.02 1
    7 2.19 (N/A)
    8 2.36 2
    9 2.53 2
    10 2.7 2
    11 2.87 (N/A)
    12 3.04 (N/A)
    13 3.21 3
    14 3.38 3
    15 3.55 3
    16 3.72 (N/A)
    17 3.89 (N/A)
    18 4.06 4
    19 4.23 4
    20 4.4 4
    21 4.57 (N/A)
    22 4.74 (N/A)
    23 4.91 5
    24 5.08 5
    25 5.26 5
    26 5.43 (N/A)
    27 5.6 (N/A)
    28 5.77 6
    29 5.94 6
    30 6.11 6

    Notice the N/A values? These 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 --> 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):

    Time (min) SE-1 - Base - Model Element Value (Numeric) (ft) SE-1 - Base - Historical Signal Value (Numeric) (ft)
    0 1 0
    1 1.17 0
    2 1.34 0
    3 1.51 1
    4 1.68 1
    5 1.85 1
    6 2.02 1
    7 2.19 1
    8 2.36 2
    9 2.53 2
    10 2.7 2
    11 2.87 2
    12 3.04 (N/A)
    13 3.21 3
    14 3.38 3
    15 3.55 3
    16 3.72 3
    17 3.89 (N/A)
    18 4.06 4
    19 4.23 4
    20 4.4 4
    21 4.57 4
    22 4.74 (N/A)
    23 4.91 5
    24 5.08 5
    25 5.26 5
    26 5.43 5
    27 5.6 (N/A)
    28 5.77 6
    29 5.94 6
    30 6.11 6

    Bit notice that there are still some N/As!

    This is because for whatever reason 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.

    I suspect that this is some kind of rounding error. Our user interface does not go to the precision of seconds or parts of seconds, but I strongly suspect that time to be 12:29:59 and possibly 12:29:59.999 etc. i.e., some value very close to 12:30:00, but not exactly on it. I assume some 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 I change my time tolerance to 121 seconds (for tolerances we do not consider increments less than 1 second), and assuming that the 12:29:59 thing above is correct, it should capture all the values properly. (I am using 121 seconds here to illustrate the point above, but in practice here I would probably just make the time tolerance 5 minutes to be sure I picked up all values).

    Time (min) SE-1 - Base - Model Element Value (Numeric) (ft) SE-1 - Base - Historical Signal Value (Numeric) (ft)
    0 1 0
    1 1.17 0
    2 1.34 0
    3 1.51 1
    4 1.68 1
    5 1.85 1
    6 2.02 1
    7 2.19 1
    8 2.36 2
    9 2.53 2
    10 2.7 2
    11 2.87 2
    12 3.04 2
    13 3.21 3
    14 3.38 3
    15 3.55 3
    16 3.72 3
    17 3.89 3
    18 4.06 4
    19 4.23 4
    20 4.4 4
    21 4.57 4
    22 4.74 4
    23 4.91 5
    24 5.08 5
    25 5.26 5
    26 5.43 5
    27 5.6 5
    28 5.77 6
    29 5.94 6
    30 6.11

    6

    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.

    So, the moral here is 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.

    Hopefully this helps explains how things are working and as mentioned above I will review the fixed 2 minutes into the future part of the time tolerance for the forthcoming SS6 release.

    Kind Regards,

    Wayne.



    Answer Verified By: Ulla Koivisto 

  • Adding an additional comment about the graph, but rather than editing the original post, I figured I would add a new reply, since it's additional information not really required for the original explanation.


    One thing that might jump out to someone reading the previous post is the 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 an 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.

    Regards,
    Wayne.



    Answer Verified By: Ulla Koivisto 

  • Thank you for the answer. I tried using the time tolerance again after reading it and now I understand better how it works. The only difference I recognized was that in your answer it says that the time tolerance looks fixed 2 min ahead and a user specified tolerance of X to the past (-X/+2). However, when I use time tolerance it looks always fixed 2 min to the past and a user specified tolerance of X ahead (-2/+X).

    Regards,
    Ulla
  • Hi Ulla,

    Yes, I noticed that we have the -X/+2 in reverse order with respect to each other, but I figured that was just a difference in the way we are describing the process rather than a difference in the way it is working.

    For reference purposes the way I am describing it is that 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 that we use.

    Also for your information in the next version of WaterGEMS (SS6), the behavior of the tolerance has been changed to +/- X, so the fixed 2 minute period no longer will apply. It will always be controlled by the user specified value, X.

    Regards,
    Wayne.



    Answer Verified By: Ulla Koivisto