FW: Action items #0011 and #0012 - A synthesis on data timsestamping

HI All,

See below the input from Benoit on Action Item #0011 en #0012.

Regards,

Gershon Janssen

From: Benoit Lepeuple [mailto:b.lepeuple@arcinfo.com]
Sent: maandag 12 april 2010 23:44
To: 'Gershon Janssen'
Subject: TR: Action items #0011 and #0012 - A synthesis on data timsestamping

Hi Gershon,

Here is the note I have prepared about time stamping (action items #0011 and #0012).

For administrative reason, I am not able to email directly to the TC list. It should have been fixed a few months ago, but still not. Could you please post it for me ?

I will close the action items and reference your post as soon as I see it in my inbox.

Thanks in advance

Benoît LEPEUPLE

Product Manager

ARC Informatique

2 avenue de la cristallerie - 92310 SEVRES - FRANCE

Tel: +33 1 41 14 36 00 - Mobile: +33 6 87 80 20 43

Email : b.lepeuple@arcinfo.com

www.pcvuesolutions.com

De : Benoit Lepeuple [mailto:b.lepeuple@arcinfo.com]
Envoyé : lundi 12 avril 2010 23:10
À : 'ws-calendar@lists.oasis-open.org'
Objet : Action items #0011 and #0012 - A synthesis on data timsestamping

Hi all,

As discussed during one of the last TC meeting, here is a short synthesis about how data time stamping and clock-related issues are dealt with in some usual protocols, standards or de-facto standards.

OPC (DA 3.0):

Within OPC, a “value” is at least a value + a quality + a timestamp (known as a VTQ item). Some other properties are mandatory, but they are out of the discussion’s scope.

Timestamps are encoded using the filetime type and should be expressed as UTC (always increasing and unambiguous). It is possible to handle Time zone by the support of a TimeBias property.

As you may know, until now, an OPC server was mainly acting as a protocol gateway (between field devices supporting protocol x or y, and an OPC client). This might be changing with OPC UA because it gives the opportunity to embed an OPC server on devices.

The fact that until now an OPC server was basically a protocol gateway raises an issue about time stamped data: As an OPC client, you get timestamps, but you cannot know if they come from the field devices, or from the OPC server itself. The question “who set the timestamp” cannot be answered except by the OPC server vendor or the system designer. See my thoughts on that below.

Here is a statement from the OPC spec:

“time stamps should reflect the best estimate of the most recent time at which the corresponding value was known to be accurate. If this is not provided by the device itself then it should be provided by the server”

The OPC spec does have the advantage of not hiding this point. In a world of heterogeneous devices/software communications it is more than hard to have an homogeneous way of dealing with time stamps.

It is always possible to add many information, but this would bring a huge overhead, without the warranty that:

- The sub-system that set the timestamp is enough “clock-aware” from the overall system point of view,

- These information are well translated from one protocol to another one.

As far as I know, OPC does not define anything related to clock synchronization, resolution and accuracy – Nothing in term of requirements to claim conformance, nothing to exchange over the wire about those. You cannot be more precise than the filetime type, but with filetimes, the resolution is 100 nanoseconds. Not that bad ;-)

A few possible values of the quality information are related to the fact that the VT you get may be quite “old” and therefore not that accurate. But they are dedicated to some usual cases of communication loss with field devices where OPC client prefer to get old but usable values instead of the last but unusable value.

IEC61850:

The IEC61850 also support time stamped data.

A timestamp is encoded the following way:

- The famous SecondSinceEpoch (the Unix way), it is expressed as UTC.

- The not less famous FractionOfSecond,

- A Time quality information:

The time quality information is a set of flags related to clock synchronization, resolution and accuracy:

- LeapSecondsKnown,

- ClockFailure, indicates that the time source of the sending device is unreliable,

- ClockNotSynchronized, indicates that the time source of the sending device is not synchronized with the external UTC time,

- TimeAccuracy, represents the time accuracy class of the time source of the sending device relative to the external UTC time. The TimeAccuracy

classes shall represent the number of significant bits in the FractionOfSecond. The accuracy ranges from 1 microsecond to 10 milliseconds.

All of these flags are mandatory except the ClockNotSynchronized.

The IEC61850, designed for substation automation lives in a more homogeneous world, therefore more information are available and should be used by all communication partners. It is gaining more and more in wind farming (with the IEC61400-25 that is based on 61850), and DER in general.

Telecontrol protocols in general:

Most of the telecontrol protocol are of course able to handle time stamped data, and they do have something like the “ClockNotSynchronized” flag of the IEC61850, or are able to raise something like “Clock synchro required”. Not all of them specify the use of UTC timestamps, and the encoding can vary greatly.

EN14908-6

This standard includes various date/time/timestamp formats as originally defined in LonMark profiles:

SFPTdataLogger functional profile --

- the data logger includes a timestamp of the receipt time for each value received by the data logger.

- it uses the SNVT_alarm_2 network data type for the time structure:

SNVT_alarm_2 network data type --

- contains an “alarm_time” field of seconds since 2000-01-01T00:00:00Z (the 0 hour of 1 January 2000, Universal Time Coordinated) in 32 bits, unsigned, without scaling. The field exhausts on the 7th of February, 2136.

- contains a “milliseconds” field of 8 bits, signed, without scaling that is associated to the seconds in the alarm_time field, with a maximum of 999 milliseconds. A value of -1 results in the milliseconds field not being significant (not used / null).

- contains several alarm-related fields but also a sequence_number that runs from 0 to 255 (unsigned, 8 bits, without scaling) used similarly to the SEQUENCE field of the iCalendar specification; as discussed in the last WS-Calendar meeting.

SFPTrealTimeKeeper functional profile --

- allows for date and time to be set according to the resolution of SNVT_time_stamp, which is “year, month, day, hour, minute, second” in 56 bits (7 bytes) with no scaling or formatting with which to contend.

- contains both summer-time offset and winter-time offset in separate values of SNVT_time_stamp. DST is disabled of the 7 bytes are all zeroes. The fields of year, minutes, and seconds should be set to zero.

- it should be noted that there is a rather complete network data type for Time Zone information called SNVT_time_zone:

SNVT_time_zone --

- contains offset from UTC in seconds (yes, seconds).

- unformatted hour, minute, and second of DST start and end.

- and, if you can imagine, the ability to state whether DST is based on the Gregorian, Julian, or EU/US method (of automatically choosing a particular day of the week within a timeframe).

In general, there are two network data types that could be confused: SNVT_time_stamp and SNVT_time_stamp_p; the latter of which is used to define a more-precise timing resolution: a timestamp with hundredths of a second resolution in a “hundredths” field, handled like the seconds-from-2000 field of alarm_time of SNVT_alarm_2 in place of the “milliseconds” field.

Just to note, there are other time-related data types defined too but those are mainly for process control, where the times are, perhaps, relative:

SNVT_time_f

SNVT_time_hour

SNVT_time_hour_p

SNVT_time_min

SNVT_time_passed

SNVT_time_sec

SNVT_elapsed_tm

The EN 14908-6 standard also defines data structures related to schedule and calendar descriptions (SFPTCalendar & SFPTScheduler profiles). The same kind of constructs exist in other standards, and in particular in iCalendar. They may be worth being investigated in a later stage.

(My) general thought:

The timestamp accuracy issue can be disturbing, but it is the same with many protocols supporting time stamped data (not to say all of them). Depending on the zoom level on a system composed of various communicating sub-systems, you usually come to a point where you have to trust your communication partner for the accuracy and real underlying source of the timestamps you are sent. If the data exchange chain is well design you can and so have to trust your communication partners, and do not consider this as an issue.

The fact that you may have special flags does not change a lot to the problem of trust: What are the criteria for a device to raise the ClockNotSynchronized or ClockSynchroRequired flags ? Device design or configuration. At the system level, a communication partner cannot know these criteria via a programmatic way in order to react accordingly.

This may be constraint by conformance statements. At least, as WS-Calendar will be clearly designed for a very heterogeneous “real” world, a statement similar to the one of the OPC spec would be worth.

The beginning of a solution could be to add a construct (not to say an element, a message, a *thing* or whatever else), so that communication partners can exchange (not negotiate) clock-awareness information:

- Question: What are your capabilities ?

- Answer: My capabilities are:

o Last clock synchro on = Timestamp of the last clock synchro or empty if clock synchro not supported (or if not known),

o Time resolution/precision = x or y (may lead to something like “ignore milliseconds” or “ignore seconds” if the time structure we will specify includes seconds/milliseconds and the time resolution of the device is not precise enough)

o Accuracy = x or y

o …

In any case, if some kind of information such as these (whatever the final wording) are added in conformance statements, it should be necessary to add them in such a construct so that communication partners can assert what the others support.

And

Such kind of information should not be located in all and every messages, but in a singular construct, used or not in a given real-life system depending on the reliability level the designer wishes to reach.

All comments are welcome.

Kind regards