Re: [Qscada-developers] R: Exciting news

[wireless <wir...@ta...>]

Jovan Kostovski wrote:

>>Besides, we both agree on pushing the RT needs as close to the
>>remote hardware as possible.
> 
> Yes that's right. In some situations we can solve the RT problem by adding
> two timestamps to the data, one would be the time that the event has occured
> set by the RTU, and the other would be the time when it has arrived on
> QScada server,
> set by the QScada server. That way we'll have the exact time when the event
> has occured and when it was registered/logged by QScada.

Well, that's very similar to what I had in mind:

I would use (2) time fields:

[parameter, timestamp, skew]

Where the timestamp is the one closest to the first element (i.e. the
RTU) and the skew is the delay(difference) in that first timestamp
and the next device that can generate an (NTP) timestamp. So between two
systems, it's virtually the same parameters, because you can add
timestamp and skew to get the second timestamp value.

However, if there are more that 2 devices running NTP between he final
scada server and the first element (RTU in this example) then you  use
skew as a  cummulative function of the maximum or total delay. That way
you keep your RT data to just 2 fields of time (original timestamp and
skew) .

But if you are having problems and need to debug, then we should have a
debug options where all of the timestamps between the final Qscada
server and the RTU are kept.

For example if somebody has 2 Qscada servers and 2 plc, in ordinary RT
mode you'd see date like this

[parameter, timestamp-0, skew]

in debug mode, you'd see

[parameter, timestamp-0, 0]
[parameter, timestamp-1, skew-0.1]
[parameter, timestamp-2, skew-1,2]
[parameter, timestamp-3, skew-2,3]
or
[parameter, timestamp-0, skew-2,3]

depending if you want to subtract or add the skew value....


skew is normally an accumulated value but can be expanded via a link
list or other such construct, when needed (debug mode).

????
James