Relative uncertainty

Hi,

in our example dcc-vacuumlab-CDG we state a relative error of indication together with its uncertainty:

            <dcc:list>
              <dcc:name>
                <dcc:content lang="en">relative error of indication</dcc:content>
              </dcc:name>
              <dcc:quantity>
                <si:real xmlns:si="https://ptb.de/si">
                  <si:value>0.0094</si:value>
                  <si:unit>\one</si:unit>
                  <si:expandedUnc>
                    <si:uncertainty>0.0060</si:uncertainty>
                    <si:coverageFactor>2</si:coverageFactor>
                    <si:coverageProbability>0.95</si:coverageProbability>
                  </si:expandedUnc>
                </si:real>
              </dcc:quantity>
              <dcc:quantity>
                <si:real xmlns:si="https://ptb.de/si">
                  <si:value>0.0033</si:value>
                  <si:unit>\one</si:unit>
                  <si:expandedUnc>
                    <si:uncertainty>0.0019</si:uncertainty>
                    <si:coverageFactor>2</si:coverageFactor>
                    <si:coverageProbability>0.95</si:coverageProbability>
                  </si:expandedUnc>
                </si:real>
              </dcc:quantity>
            </dcc:list>

HTH

Hi, Thomas. Thanks for replying!

I've read this example, so I think my issue was not clear enough or the solution is right there and I´m not able to see it.

In this example you mention, the Error of the Indication, the content of si:value, is also expressed in relative. As I may interpret from the 17025:2017, the uncertainty can either be expressed in relative or in absolut. The GUM says something similar, but is not as clear as the 17025.

In GUM 2008 The bullet 7.2 c) include the relative combined standard uncertainty uc(y)/│y│, │y│ ≠ 0, when appropriate;

I was thinking to solve this issue with a standalone uncertainty but it will require a list. I don´t know if that´s the way to solve the issue and I haven´t tested it yet.

Best Regards Diego

What do you mean by standalone uncertainty? Isn't an uncertainty always related to a value? I guess (not sure) there is no way expressing something like 10.5V with an uncertainty of 0.13%. However, wouldn't (10.5 +/- 10.5*1.3E-3)V solve your issue?

Hi, Thomas,

OK, may be it´s not possible to express the measurement result as 10.5V with an uncertainty of 0.13%.

The representation (10.5 +/- 10.5*1.3E-3)V would solve the problem but is not my interpretation of the 17025 and the GUM, to force the uncertainty to be absolut. The xml will also be human readable and it should support the representation of a relative uncertainty -or I think it should-.

By standalone I ment the 4th bullet of this issue: #22 (closed)

And the EXAMPLE-202:

https://gitlab1.ptb.de/d-ptb/d-si/xsd-d-si/-/blob/master/examples/SmartCom_A1.2.3_examples.xml

I haven´t check standalone solution yet.

Best regards Diego

Ok, I see. #28 (closed)

Hello, Thomas, I was searching for a solution for this issue, may be one of this could get through it.

Valid example:

measurand: 0,1989 pC/(m2/s2)

Relative Uncertainty: 1,1%; k=2; 0,95 cP

<si:real>
	<si:label>Sensivity; Relative Uncertainty = 1.1%</si:label>
	<si:value>0.1989</si:value>
	<si:unit>\pico\coulomb\meter\tothe{-1}\second\tothe{2}</si:unit>
	<si:expandedUnc>
		<si:uncertainty>0.0021879</si:uncertainty>
		<si:coverageFactor>2.0</si:coverageFactor>
		<si:coverageProbability>0.95</si:coverageProbability>
	</si:expandedUnc>
</si:real>

One solution:

<si:real>
	<si:label>Sensitivity</si:label>
	<si:value>0.1989</si:value>
	<si:unit>\pico\coulomb\meter\tothe{-1}\second\tothe{2}</si:unit>
	<si:expandedUnc>
		<si:label>Relative Uncertainty = 1.1%</si:label>
		<si:uncertainty>0.0021879</si:uncertainty>
		<si:coverageFactor>2.0</si:coverageFactor>
		<si:coverageProbability>0.95</si:coverageProbability>
	</si:expandedUnc>
</si:real>

Another type of solution

<si:real>
	<si:label>Sensitivity</si:label>
	<si:value>0.1989</si:value>
	<si:unit>\pico\coulomb\meter\tothe{-1}\second\tothe{2}</si:unit>
	<si:expandedUnc>
		<si:absolutUncertainty>0.0021879</si:absolutUncertainty>
		<si:coverageFactor>2.0</si:coverageFactor>
		<si:coverageProbability>0.95</si:coverageProbability>
	</si:expandedUnc>
</si:real>

<si:real>
	<si:label>Sensitivity</si:label>
	<si:value>0.1989</si:value>
	<si:unit>\pico\coulomb\meter\tothe{-1}\second\tothe{2}</si:unit>
	<si:expandedUnc>
		<si:relativePorcentageUncertainty>1.1</si:relativeUncertainty>
		<si:coverageFactor>2.0</si:coverageFactor>
		<si:coverageProbability>0.95</si:coverageProbability>
	</si:expandedUnc>
</si:real>

<si:real>
	<si:label>Sensitivity</si:label>
	<si:value>0.1989</si:value>
	<si:unit>\pico\coulomb\meter\tothe{-1}\second\tothe{2}</si:unit>
	<si:expandedUnc>
		<si:uncertainty unit="absolut">0.0021879</si:uncertainty>
		<si:coverageFactor>2.0</si:coverageFactor>
		<si:coverageProbability>0.95</si:coverageProbability>
	</si:expandedUnc>
</si:real>

<si:real>
	<si:label>Sensitivity</si:label>
	<si:value>0.1989</si:value>
	<si:unit>\pico\coulomb\meter\tothe{-1}\second\tothe{2}</si:unit>
	<si:expandedUnc>
		<si:uncertainty unit="relative">0.011</si:uncertainty>
		<si:coverageFactor>2.0</si:coverageFactor>
		<si:coverageProbability>0.95</si:coverageProbability>
	</si:expandedUnc>
</si:real>

Best Regards!

Nice! Following #28 (closed) I'ld think something like:

<si:expandedUncType>relative</si:expandedUncType>

would be a suggestion too.

Should <si:absolutUncertainty>0.3465</si:absolutUncertainty> not be <si:absolutUncertainty>0.0022</si:absolutUncertainty>?

Regards Thomas

Yes it´s wrong, I make a mistake in the calculation, but if you want to have 1.1% of relative expanded uncertainty, the number should be 0.0021879 so you can reconstruct that exact number further, in the pdf for instance.

Good, that feature would solve the issue! I´ll look into it!

Is it explained somewhere? I can´t see it in 2.0.0

Thanks!

@DCoppa @bock04

Dear all the relative uncertainty is not included in the D-SI on purpose. I hope to be able to lay out the reasons the members of the SmartCom project and DCC developping team had found in a very early stage of the development (two years ago) that lead to the decision for the absolute uncertainty statements.

The philosophy underpinning to the whole D-SI data model design is to definie a minimum set of information for the exchange of metrological data suitable for machines, key words: "universal, unambiguous, safe and easy to understand". The most important implementation principles of that philosophy is

§ 1: Using SI units and in the best case only units directly expressed by using SI-base units.

§ 2: No redundant ways of providing information to establish a minimal number of varaints to provide data.

Data and data exchange following these rules was identified as the essential need for future machine-to-machine usage of data, where the implementation of software interfaces, interoperation and reuse of data is made as easy as possible. Each additional variant of ways to provide data makes software development more expensive. Especially users of the data in smaller companies will need to buy in the software for working with the data and each variant makes the tools more expensive for them. While humans today have no problems to interprete and handle the data, machines in future need to implement methods to hadle the data provided in all the possible variants.

(By the way - this is one principle of the SI too: having a minimal set of universal units to establish an easy to maintaine and easy-to-understand system of measurement wordwide instead of a big system with no more handleable number of individual units)

After this long introduction now some specific considerations behind the uncertainty

The D-SI decision for "only absolute uncertainty statements" is based on the following arguments:

si:real is a VIM "quantity value" where (in si:real) the number (numerical value) and uncertainty value have the same unit (no redundant unit statement + no risk to have ambiguouse units between number and uncertainty)
For subsequent calculations with the data the absolute uncertainty value has the benefit that the arithmetic errors that occure at calculation are lower. E.g. a relative uncertainty adds an arithmetic error two times: first when it is calculated from absolute data and second, when the absolute uncertainty is calculated from the relative uncertainty again.
In many existing statements of the relative uncertainty in analogue documents it is not clear how it was calculated, in particular, what the reference value is (e.g. calibration: does it refere to the measured value or some nominal value, which is typically not documented)
with only absolute uncertainty, there are 8 variants to provide a real quantity value with the expanded uncertainty in the current D-SI that a machine (software) would need to be able to handle. Allowing both (relative or absolute uncertainty) would increase the number of options to 16 varaints, if both relative and absolute uncertainty can be provided at the same time, it gets even 24 variants (all of which a software must be able to distinguish).
And last but not least: "percent" as unit is not recommended in the SI (it is no SI unit at all).

The ISO 17025 and GUM both considere absolute and relative uncertainty which is certainly ok in a world where data is only used and interpreted by humans or where data is only exchanged in closed systems. These guidelines have never been developed thinking of digital data formats, machines reading data and the needs of machine-interoperable data that we have now with digital transfromation in metrology. The digital data formats certainly will need to go beyond the existing guidelines for the human world and many definitions will need to be thought over again if they are realy suitable for machines and a "payable" digital transformation in the future. But this certainly cannot be solved in a Git issue.

In the human readbale presentation of data there will certainly be relative uncertainty one common need for many years in the future. But it can be calculated by the software (midddleware) that is displaying the data to humans (and calculation from the absolute uncertainty is easy).

This leaves the last question how to deal with the relative uncertainty now in the D-SI?

There are several considerations (some already outlined before):

If a software needs to calculate with the relative value: create it with the middleware from the absolute value. (it should be an very easy to establish calculation in many software interfaces)
If it is wished to report the relative uncertainty in the data: use a si:real element to encode the relative uncertainty value, si:list can be used to align the value with the quantity value it is refering to. This could besupported by agreeing on common terms for labels that indicate that the si:real is a "relative uncertainty" (or a "relative humidity", or ...).
Using the option to embed the D-SI in high-level an domain-specific data structure: E.g. the DCC is a high-level structure specific for the calibration domain. It implements a dcc:qauntity that contains the si:real but also calibration specific metadata in addition to the pure real quantity (like names in multiple languages). Your high-level data structure similar to a DCC may also extend the content of si:real to a data element that is clearly providing the relative uncertainty and all metadata that is for example explaining how the relative value was calculated.

Finally, the D-SI is subject to development and update towards more internationally agreed reccomendations. Especially the recommendations for SI based data (an SI core representation) from CIPM will be an important international driver to see, what internationally acceptable representations would be. Here it is at the moment completely open in which way the uncertainties would best be provided.

Sorry for the long text. It is the SmartCom view that certainly would lead to more questions and may add to future discussion and the exchange of different views on the topic.

If there is interest, we may even go for a virtual meeting on this topic!

@DHutzschenreuter decision and argumentation is absolutely understandable from my point of view. Thank you for sharing.

Dear Colleagues, there is one more argument from the practical side which should be added to @DHutzschenreuter 's considerations: In the technical world, a value can be related to more than one other value to build a relative number (a percentage). So the percentage value is not un-ambiguous and needs additional contextual information which is unclear how to standardize. However, in the end, this percentage conversion addresses only the habits of the human reader and adds no technical value. Therefore I also support the strategy that it should be avoided, if not excluded.

Another complexity arises if the measurand has dimension "one". Then it would be very hard to differentiate between the uncertainty in the dimension of the measurand and any relative uncertainty. So, please avoid....

@DHutzschenreuter I think that if the D-SI will not support % it will be a big issue for the Process Industry, most of Pressure transmitters in process industry are calibrated according to "Percent of Span", and Flow transmitters to "Percent of Reading".

From ANSI/ISA-S51.1-1979 (R 1993) Standard: Process Instrumentation Terminology

Accuracy, measured: The maximum positive and negative deviation observed in testing a device under specified conditions and by a specified procedure. Typically expressed in terms of the measured variable, percent of span, percent of upper-range value, percent of scale length or percent of actual output reading

@KRiska @DHutzschenreuter: This is exactly the problem that I have described above: For a given percentage statement, you can never know what the divisor was, it might have been "measured value" ("actual output reading") or it might have been "span" or whatever. so you would need additional contextual information, which is yet not standardized.

On the other hand, if you use the concept as we have it now (=absolute values, no percentages), every user can convert every value into a percentage of his choice. This is the big advantage and there is no disadvantage at all. DCC values are meant to feed in a machine that "processes" data anyway, so calculating percentages should be no problem.

closed

reopened

I have re-opened the issue. I do not understand if this is solved. I have special doubts if we have gained enough understanding since the inital text quotes:

"The measurement uncertainty of the measurement result presented in the same unit as that of the measurand or in the term relative to the measurand (e.g. percent)"

While in the above discussion also percent of span was mentioned which clearly would contradict ISO 17025.

In such unclear cases, I would plea for NOT calculating a relative value and leave this to the user, but supply all absolute values in the DCC to enable the user to calculate a relative value according to his wish.

The issue is closed, as there have been no further discussions since over one year.

The following appraoches to represent relative uncertainty could be followed: 1.) Either use the si:real to state the value of the relative uncertainty in your data (can also be used with unit percent, #31 (comment 11776)) 2.) Or use one of the DCC structures for relative uncertainty statements.

closed

Relative uncertainty

Designs

Child items ...

Activity