Double datatype loses precision (resolution) for values > 2^52. It is not possible to define a range of [-2^63 .. 2^63-1], or [0..2^64-1] using double. Two cases where using a range type of double for a variable type of UINT64 or INT64 can cause malfunctions are for variables of UTC time and position in encoder increments. Motion applications apply UTC time stamps to events. 52 bit precision in defining range will result in loss of time precision 142.8 years after the time reference (1970). Granted that is far in the future. However, time precision is lost for the next 584,799 years of the available 584,942 years supported by the UINT64 datatype.
Motion applications will malfunction if position command or feedback loses precision. There are motion applications that run in one direction for the life of a machine (e.g., a rotary turret used to fill bottles). Position as an INT64 counts up to 2^63-1 and then rolls over to -2^63 with no loss of precision. Position as a double will count to much larger values at the expense of loss of precision. This is not acceptable. The position variable and the position ranges need to have the same precision (datatype).

After discussing with Marius we concluded that the Double used in Range will not meet the requirements of motion.
Since Range is fixed as a Double there is no way to use Range for this use case. Any change to Range would be a breaking change and therefore not an option.
Recommended that the Motion group look at subtyping BaseAnalogType to include two individual sub-properties representing the low and high range with a DataType of Number.
Also suggested they propose this type to the Harmonization group to see if there would be applicability of this new type beyond Motion.
Marius will bring this back to the Motion group.

The Motion WG discussed our options. The plan is that the WG shall propose a new variable (or object) type that extends the capabilities of AnalogUnitRangeType for motion requirements. It will consider:
o Properties for min & max values
o A range property with a data type that matches the variable value data type.
o Motion specific needs for write access control.
Once the motion WG has a solid proposal, we shall provide this to the Harmonization WG for consideration for part 8. We should share the new type with the Instruments WG to assess their interest.

Blocked - waiting for proposal from Motion WG.

The Motion WG discussed our options. The plan is that the WG shall propose a New variable (or object) type that extends the capabilities of AnalogUnitRangeType for motion requirements. It will consider:

• properties for min & max values
• A range property with a data type that matches the variable value data type.
• Motion specific needs for write access control (i.e. write access based on Functional Entity state).
  Once the motion WG has a solid proposal, we shall provide this to the Harmonization WG for consideration for part 8. We should share the new type with the Instruments WG to assess their interest.

Paul has sent a proposal to Karl.

We agreed on a slightly different solution in today's UA call. Manuel Jacob will create a new Part 8 with the revised proposal.

Added AnalogUnitNb types which solve this. It is in "OPC 10000-8 - UA Specification Part 8 - DataAccess 1.05.07 Draft.docx" in "Drafts for Review 1.05" folder.
Was discussed and approved by the UAFX Instrument group.

Agreed to changes previously reviewed in the draft.