Add consistency check: there should not be two variables with same value reference but different types

[ghorwin]

See fmus_2.0_cs_win64_AMESim_15_ClassEAmplifier -> defines two variables with same value reference, yet different types:

    <ScalarVariable name="maxTimeStep" valueReference="536870912"  ... >
         <Real unit="s" ... />

     <ScalarVariable name="errCtrl" valueReference="536870912" ... >
          <Integer min="0" max="2" start="0"/>

This looks like an error. The standard does not seem to forbid this, though.

Still, it looks strange and could be flagged with a warning in the compliance checker (in case it is an error).

[ghorwin]

A side note on the FMI standard: IMHO, it would have been easier to enforce unique value references than to introduce the concept of a "variable index" later in order to uniquely identify variables in the dependency section...

And, if you think of the variable index as something like a hash value to the unique variable name (just to make coding easier and avoid string handling for the c-guys among the FMU coders) a unique value reference would have done the job as well. Oh well... :-)

[t-sommer]

FMI 2.0 does not require value references to be unique across types (or even for the same type).