580   Eliminate INT128 BasicType

Created: 06 Nov 2007

Status: In Force (green)

Part: Part 7-2 (2003)

Links:

Page: 21

Clause: 5.5.2

Paragraph: Table 2

Category: Issue for edition 2 of this part

Issue

The INT128 datatype seems impractical to implement on almost any computer, but especially on IEDs. There is no standard way to store INT128 values on any modern computer. And the maximum value of an INT128 is larger than anyone is likely to need. The maximum value for an unsigned 64-bit integer is 18,446,744,073,709,551,615 (over 18 quintillion). An INT128 value would be roughly that number multiplied by itself. I won't attempt to even write it. Currently, INT128 is only used for the "actVal" and "frVal" of BCR (Binary counter reading).

Proposal

Eliminate the INT128 datatype and use INT32 or INT32U in BCR. The maximum value for INT32U is 4,294,967,295 (over 4 billion). If that is not big enough, add an INT64 or INT64U datatype and use that. The INT64U could handle over 18 quintillion. The INT64 and INT64U types may not be supported as native datatypes on many embedded systems used for IEDs, but it would be reasonable to create software to perform INT64 operations on any 32-bit system.

Discussion Created Status
WG10 Meeting - Fredericia.
Accepted to remove the INT128 and replace it with INT64. 		27 Feb 08 In Force (green)
Three additional points:
1. The engineering value includes actVal and pulsQty and unit.multipler. If actVal is limited to a small range (such as INT32) then either pulsQty or unit.multipler SHOULD be user configurable.
2. IEDs which report only positive values for energy (example: SupWh) must ensure that a count rolloever does not cause negative values to be sent. For INT32, this means rollover at 2**31-1 and not 2**32-1. If the server rolls over at 2**32-1 then a INT64 (or INT128) must be reported.
3. John's suggestion of using INT32U will not allow negative values of TotWh to be transmitted from the server.

Also, conformance testers might soon begin comparing the results of GetDataDefinition with part 7-3 and fail devices which do not report INT128 as the data type of BCR.actVal. Once this testing begins, it reasonable to require that rollover values at "unexpected" values be explained in the PIXIT (for example, rolloever of MMTR.SupWh at a point other than 2**127-1)

Proposal:
a) Change INT128 to INT64 in BCR (part 7-3)
b) Replace INT128 definition in 7-2 with appropriate INT64 definition
c) Require declaration of the range of individual actVal attributes in the PIXIT (or a statement that the range is approximately +/- 2**63) 		22 Feb 08 Discussion (red)
Just one clarification - the maximum value that can be counted has nothing to do with the unit nor with the multiplier of the units. In the BCR common data class we have a mandatory attribute pulsQty that determines the value of one count. So the maximum value is influenced by the pulsQty. 07 Feb 08 Discussion (red)
I disagree with the following affirmation of Bruce:
"Usage of NCR includes (signed) MMTR.TotWh which implies that this is energy accumulators in watt-hours"
BRC has got an attribute units, that itself contains a multiplier. The name "TotWh" implies that the SIUnits is "Wh" however, the multiplier can goes up to 10^24!
Using the multiplier could be a way to limit the actVal and frVal to an int32. The backward compatibility issue should not exists since I believe that all the current implementations used an int32!
17 Dec 07 Discussion (red)
The problem is not with the maximum range, but with the GetDataDefinition which is required to declare the size of BCR.actVal to be 128 bits in order to match existing part 7-3 clause 7.3.8.
If we allow GetDataDefinition to return values other than that specified in 7-3 then we will have large interoperability problems.
One change that we CAN make is to modify 7-2 table 2 entry for INT128 to state that the range is only 64 bits. However, it will be very confusing that INT128 really means 64 bits but INT32 really means 32 bits. 		15 Nov 07 Discussion (red)
I think we agree that the problem is not in ASN.1 encoding of a INT128. Therefore I propose to keep it as an INT128 value in the model to avoid backwards compatibility issues - if it is used in a server, that counts a value that does not exceed the 32Bit range, the value will never use the full range and can be handled as 32 Bit. In the PIXITs of the server, the maximum range can be defined at which an overflow would occur. 15 Nov 07 Discussion (red)
INT128 is presently used only for BCR. Usage of NCR includes (signed) MMTR.TotWh which implies that this is energy accumulators in watt-hours. Large generators produce about 1 gigawatt-hours per hour and will overflow a 32 bit (signed) value in under 3 hours. I suggest using 64 bit signed values for BCR.This would also require that table 2 in clause 5.5.2 replace the row for INT128 with a row apprpriate for INT64.

Refer also to 7-3 comment (comment 582 ?) 		14 Nov 07 Triage
We fully agree with john Bruder; but instead of suppressing INT128 symbol, we suggest to treat it as an INT32 (limiting range, that is what we implemented for Ed.1): this preserves any bakward compatibilities. 07 Nov 07 Triage

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.12.13.1