Re: [Qscada-developers] R: Exciting news

[Jovan K. <cho...@gm...>]

Hi,

On 11/16/06, wireless <wir...@ta...> wrote:
> 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.

Really good concept. That way we can measure the time delays
of the parameter data when travelling through devices until it gets
to the QScada server.

There is a small problem: Not all field devices (RTUs etc.) keep track
of time. The time of the measurement depends of the device that
reads that information. All the other times are relative to that time.
So if the first device, the one that reads the informaton doesn't have
a clock, who will timestamp that information? The first device on the
road that has a clock, or the QScada server?

The method that I proposed (t_occured an d t_arrived) is based on the
experiences that I have from working on development of SCADA systems.
So if the device that read that  parameter doesn't have a clock only the
t_arrived parameter is filled.

I personally like James' method more because time delays between
devices can be measured, but the drawback is that every device in the
system has to track the time (have a clock).

GREETZ, Jovan