1435   TimeAccuracy: handling on client of not significant bits of FractionOfSecond of time stamp

Created: 25 Aug 2015

Status: In Force (green)

Part: Part 7-2 (2010; Edition 2)

Links:

Page: 27

Clause: 6.1.2.9.3.3

Paragraph: Table 8 and next

Category: Issue for edition 2 of this part

Issue

Part 7-2 defines that TimeAccuracy represent the number of significant bits in the FractionOfSecond of time stamp. Type TimeStamp (according part 8-1) contains all – 24 bits – of FractionOfSeconds and also contains - on 8th octet - the TimeAccracy. A server is not obligated to set in time stamp the non-significant bits to 0.

It is not defined how a client should handle non-significant bits of FractionOfSeconds in received time stamps when accuracy < 24 bits. When servers are using different accuracy how the client shall chronologically sort the process data?

For example: Reported time stamp contains FractionOfSeconds: hex 93 F7 CE = 1001 0011 1111 0111 1100 1110b - decimal: 9697230 --> multiplied by 2^-24 --> 0,57799994945526123046875 --> 578 ms
server with class:
- class T2 - accuracy 14 bits -> 93 F4 00h = 9696256 --> 0,57794189453125 --> 578 ms
- class T1 - accuracy 10 bits -> 93 c0 00h = 9682944 --> 0,57714843750000 --> 577 ms

Proposal

To present the process data chronologically the client shall take into account the significant bits from the FractionOfSeconds, based on what the server specifies in the TimeAccuracy and ignore (truncate) non-significant bits of FractionOfSeconds.

Discussion Created Status
04 Nov 15 In Force (green)
Ed2.1 enhance the text of the TimeAccuracy as:

This diagram illustrates the minimum for n, to conform to time accuracy performance class defined in IEC 61850-5; the number of significant bits to use for a corresponding coding of the field FractionOfSecond shall be at least “n+1”. 		19 Oct 15 Ballot Period
21 Sep 15 Discussion (red)
Ed2.1 enhance the text of the TimeAccuracy as:

This diagram illustrates the minimum for n, to conform to time accuracy performance class defined in IEC 61850-5; the number of significant bits to use for a corresponding coding of the field FractionOfSecond shall be at least “n+1”. 		21 Sep 15 Discussion (red)
Accepted that the wording can be misunderstood. I suggest to change as follows: 'Number of significant bits in the coding of FractionOfSeconds'.
How the client handles the FractionofSeconds in a received time stamp is a client specific issue and not standardized. 		17 Sep 15 Discussion (red)
If a client calculates the time stamp always using all bits of FractionOfSeconds, whatever TimeAccuracy received, then it handles all bits as "significant". The sentence (-7-2: 6.1.2.9.3.3) „The timeAccuracy classes shall represent the number of significant bits in the FractionOfSecond.“ has no impact on value of the time stamp and leads to misunderstandings.
The TimeAccuracy is then information like some "enum”: 'class T0', 'class T1'…, and has no impact on bits, has only an impact on rounding of the decimal result ('class T0' means – "round to 10ms" ).
Is this sentence in -7-2 then correct?
01 Sep 15 Discussion (red)
The class accuracy declared by the time stamp indicates how the time stamp including all the bits of the fractionOfSeconds is accurate.
A class T1, accuracy of 1 ms, indicates that the real event occured at fractionOfSecond (whole bits) +- 0,5ms.
Truncating is a quick method to compute a fraction of seconds but introduces an addtional inacuracy in the time stamp representation.
(see attached document).
The most accurate representation of the timeStamp can be achieved with using all the bit of the fraction of second but is not mandatory. 		28 Aug 15 Discussion (red)

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.12.13.1