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.

Parents
  • 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 

Reply
  • 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 

Children