1361   Variable length Quality encoding

Created: 05 Mar 2015

Status: In Force (green)

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

Links:

Page:

Clause: 8.2

Paragraph:

Category: Issue for edition 2 of this part

Issue

This clause specifies for Quality: "shall be encoded as a variable length bit-string. Bits that are not conveyed shall assume the default value as specified in this Subclause". The BER encoding rules state that trailing 0-bits can be removed. This always implies a default value of zero! Which may cause a mismatch in case a (future) default value is 1.

Is such 0-bit removals allowed for quality in GOOSE messages? Same for variable bit-strings values in the report messages?

Proposal

Clarify if/when removing of trailing 0-bits is allowed for variable length bit-strings.

Discussion Created Status
12 May 15 In Force (green)
20 Mar 15 Ballot Period
Final Proposal:
The appropriate number of used/unused bits must be conveyed for all bit strings (PACKED-LIST, CODED-ENUM, ...) so that forward semantic compatibility can be maintained.
Therefore, 0 length bit strings are not allowed within the context of IEC 61850-8-1. 		20 Mar 15 Ballot Period
The issue is not the BER ASN.1 encoding, but rather knowing the semantics that are being conveyed. The issue is forward compatibility.

For quality, assume that one Edition has semantics for 13 bits, in another 14 bits. The number of used/unused bits must be conveyed in 61850 in order for the consumer of the information to understand that the 14th bit has no meaning.

Therefore, it is the need to convey number of used/unused bits that requires an encoded/non-zero length bitstring. 		20 Mar 15 Discussion (red)
additionaly according to 8.1.2.1
The amount of bits conveyed by a sent variable length bit-string shall allways be equal to the maximum length of the defined variable length bit-string at the sender side. 		09 Mar 15 Discussion (red)
BER encoding of bit string allows to remove zeros at the end of the string ONLY if the IdentifierList is used.
61850 must take care of forward / backward compatibility. Not sending the real length of the bit-string defined in the standard leads to backward / forward compatibility issues as soon as a newer version of the standard extends the bit string IdentifierList, as a receiver can not determine what is the IdentifierList used by the sender.
Additionally, the encoding of Data follows an implicit definition. Therefore, only the application layer can determine on reception what is the Data being received: OptFlds? q? TrgOps? InclusionBitString? A implicit tag for each bit-string type only allows decoder to guess the Identifier List that is being decoded (guess because again, we will have versioned IdentifierList).
PACKED-LIST shall there be mapped to variable-length bit strings, which length shall be set to the versioned length of the PACKED-LIST.
Forward compatibility is garantee with "Bits that are not conveyed shall assume the default value as specified in this subclause". A new receiver can therefore default the bits that were not conveyed (because not known) by a sender that uses a former version of the PACKED-LIST. 		06 Mar 15 Discussion (red)

 

Privacy | Contact | Disclaimer

Tissue DB v. 24.12.4.1