817   Fixed-length GOOSE float encoding

Created: 03 Feb 2012

Status: In Force (green)

Part: Part 8-1 (2011; Edition 2)

Links:

Page: 139

Clause: n/a

Paragraph: n/a

Category: Issue may impact interoperability of implementations of Edition 2

Issue

The fixed-length GOOSE encoding for 32-bit floating point numbers specifies a length of 4 bytes, in IEEE 754 format. It is also claimed that fixed-length encoding should be backwards-compatible with existing GOOSE decoders. Existing GOOSE implementations encode 32-bit floats in 5 bytes, with the first byte being used to indicate the number of bits used for the exponent. Therefore, there is no guarantee that 4-byte fixed-length floating-point values will be decoded correctly.

Proposal

Possible solutions:

1) Do nothing, because this encoding format is optional, i.e., subscribers are responsible for only subscribing to fixed-length encoded datasets if they can decode them.

2) State in IEC 61850-8-1 that datasets containing fixed-length floating-point values may not be decoded correctly.

3) Change the fixed-length encoding of 32-bit floating point values to match existing implementations.

4) Create a non-backwards-compatible fixed-length encoding. At the same time, change the byte length for integers to native sizes, e.g., use 4 bytes for 32-bit signed integers, rather than 5 bytes (as needed for backwards-compatibility).

Discussion Created Status
02 May 12 In Force (green)
Final Proposal:
Change Table A.2: Encoding allData in Fixed-length GOOSE Message.
Basic Data Type Float 32
ASN.1 Tag 0x87
ASN.1 Len = 5
Comment: MMS Data Production: first byte=8, remaining 4 bytes represents the floating point number in IEEE 754 single precision format.
14 Feb 12 Ballot Period
Mail from Herb Falk:
I agree with George....We have to maintain compatibility.

Mail from Wolfang Wimmer:
I support George to take option 3. One of the goals was compatibility with the current format, so that (hopefully all old) receivers do not have to care if the sender uses fixed format or the 'old' variable format.
14 Feb 12 Discussion (red)
Mail from George Schimmel:
The variable-length (Ed1) Goose encoding for data (including floating point) imports the MMS Data production. The MMS Data production specifies a flexible format which includes the ASN.1 tag and length, plus an additional byte which defines the length (in bits) of the exponent. As defined in the MMS spec, if the overall length is 5 and the exponent length (1st byte) is 8, the remaining 4 bytes represents the floating point number in IEEE 754 single precision format. Implementers are free to use other overall lengths and exponent lengths, but I believe that all of the current implementations use the IEEE 754 format anyway. The IEEE 754 format specified in the fixed-length Goose protocol means that the mantissa must be 23 bits plus a sign, and the exponent must be 8, so that the data exchange is unambiguous. The only issue is that the ASN.1 length for FLOAT32 in 8-1 Table A.2 should technically be a 5 instead of 4 to include the extra exponent length byte used in the MMS Data production. With that change, all data can be decoded using the same logic as in variable length ASN.1. The extra byte is not really needed (since it will always have the value 8), but it will simplify implementations. I guess that this is option 3.


14 Feb 12 Discussion (red)

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.12.13.1