Messwerte und ihre physikalischen Einheiten digital interpretierbar verarbeiten!

Während wir in den vergangenen Jahren ein auf standardisierbaren Prozessen basierendes und vollständig zur DIN EN ISO/IEC 17025 konformes digitales Managementsystem etabliert haben, waren wir lange Zeit wirklich überzeugt davon, dass viele „Probleme“ der analogen Arbeit bereits durch digitale Transformation gelöst worden sind – und zwar so, dass man sich auf dem Feld der Software-Entwicklung bereits auf eine gelebte Praxis stützen kann. Wir sind beispielsweise davon ausgegangen, dass die Verarbeitung physikalischer Einheiten in Datenbanksystemen durch zahlreiche frei verfügbare digitale Bibliotheken hervorragend abgedeckt ist.

An vielen Stellen wurden wir eines Besseren belehrt und mussten feststellen, dass zwar enorm viel Literatur – insbesondere im Bereich der Metrologie – existiert, gleichzeitig aber wenige wirklich tragfähige Bibliotheken, die uns Software-Herstellern das Leben im Bereich der Verarbeitung von Daten in Verbindung mit physikalischen Einheiten erleichtern.

Etwas überspitzt – und ketzerisch – könnte man sagen: Die ganze Welt spricht von Daten und künstlicher Intelligenz und was KI alles schaffen kann. Wir können aber nicht einmal Daten, Grenzwerte und Messunsicherheiten in Kombination mit ihren physikalischen Einheiten international auf einer Verständnisebene digital und maschineninterpretierbar speichern. Hierbei werden fast immer domänenspezifische Programmierung und die Kompetenz des Menschen notwendig.

Einheitendatenbanken heute!

So ist es heute in nahezu allen Software-Produkten, die Messdaten und deren physikalischen Einheiten verarbeiten, nicht gelöst, dass die daraus resultierenden Daten von digitalen Prozessen oder Maschinen weiterverarbeitet werden können. Einheitendatenbanken liefern heute in den meisten Fällen die Namen bzw. die Messgröße, die Bezeichnung einer physikalischen Einheit und das Symbol, welches zur Einheit gehört, als Buchstabe in einem Textfeld („String“). Warum? Weil man bislang einfach nichts anderes gebraucht hat. Schließlich werden Millionen von Kalibrierscheinen pro Jahr immer noch per Post oder per Mail versendet und von Menschen gelesen und Interpretiert!

Hier ein Beispiel für typische Inhalte von Einheitendatenbanken als String-Values:

Um nun in einer Software (z.B. für die Prüfmittelverwaltung, die Spezifikation von Kalibriervorgaben oder die Verifizierung von Kalibrierergebnissen) Messwerte erfassen zu können, ist es bekanntlich notwendig, die Einheit mit einem Zahlenwert zu kombinieren.

Was Nutzer:innen in einer Software als Messwerteingabe bezeichnen können, da sie die Kombination der Zahl „10“ und dem kleinen Buchstaben „m“ als Messwert (in der Einheit „Meter“) interpretieren können, benötigt allerdings menschliche Intelligenz. User benötigen das Wissen, die Erfahrung und die Kompetenz, „10 m“ als Längenmesswert zu interpretieren. Wenn Sie den Längenmesswert „10 m“ nun in einem Messbericht ausdrucken, benötigt auch der Empfänger der Ergebnisdaten entsprechendes Wissen, Erfahrung und Kompetenz, das Ergebnis als Längenmesswert zu interpretieren.

Ein auf diese Weise notierter Messwert ist menschenlesbar, menscheninterpretierbar, ggf. maschinenlesbar, aber definitiv nicht (oder nur mit domänenspezifischer Programmierung) maschineninterpretierbar. Die Maschine oder Empfänger-Software weiß nicht, dass es sich bei dem Messwert um einen Längenmesswert in der physikalischen Einheit „Meter“ handelt. Der Vollständigkeit halber: Um ein wirklich tragfähiges Messergebnis repräsentieren zu können, fehlt dem Messwert übrigens noch die Angabe der Messunsicherheit.

Die spannende Frage für uns: Wie können wir physikalische Einheiten in unserer AUDITTRAILS-Plattform darstellen, sodass ein echter Mehrwert für die Speicherung bzw. Interpretation der Daten entsteht – und wir Prozess-Inputs (z.B. ein Kalibrierergebnis als DCC) sowie Prozess-Outputs (z.B. ein Messergebnis) zukunftssicher abbilden können?

Unsere mittlerweile vielfach validierte Vorgehensweise basiert auf dem digitalen Einheitensystem D-SI, einem State-of-the-art-Ansatz zur maschineninterpretierbaren Verarbeitung von Einheiten – und zwar so, dass gleichzeitig jede beliebige im D-SI-Schema definierte Einheit auf die sieben SI-Basiseinheiten rückführbar dargestellt werden kann.

Einheitendatenbanken morgen: So funktioniert das „D-SI“ System?

Das D-SI-System definiert zusätzlich für jede physikalische Einheit einen Identifier, der für die Darstellung einer physikalischen Einheit im Programmcode Anwendung findet – ein Beispiel:

Eine kleine Anmerkung: Die Definition des D-SI wurde im EMPIR-Projekt 17IND02 „Communication and validation of smart data in IoT-networks“ (SmartCom) vorgenommen und veröffentlicht.

Die D-SI-Definition enthält neben den sieben Basis-SI-Einheiten eine Reihe weiterer definierter Einheiten. Die SI-Basiseinheiten werden zudem mit der Klasse „Platin“ bezeichnet, die besagt, dass diese Einheit selbst eine SI-Einheit oder erweiterte SI-Einheit ist.

In der AUDITTRAILS-Software-Entwicklung wurde nun das digitale Einheitensystem zugrunde gelegt. Die Herausforderung ist hierbei aber nicht, physikalische Einheiten auf diese Weise abzubilden, sondern Software-Usern, die z.B. die Kalibrierspezifikation (= Digital Calibration Request, DCR) für ein Prüfmittel definieren und dazu eine abgeleitete physikalische Einheit (z.B. ml/min für den Durchfluss) benötigen, ein Werkzeug bereitzustellen, das es erlaubt, jede beliebige zusammengesetzte Einheit zu definieren, die im Rahmen der Prüfmittelüberwachung benötigt wird. Diese muss von einer Software validiert und korrekt rückführbar dargestellt werden können.

AUDITTRAILS hat hierfür einen programmatischen Ansatz entwickelt, mit dem sich jede beliebige Einheit über einen Einheitenkonfigurator erstellen und rückgeführt auf die SI-Einheiten auflösen lässt. Der Einheitenkonfigurator basiert laut D-SI Definition auf dem Fakt, das jede physikalische Einheit als Produkt von SI-Einheiten, Präfixen und Exponenten dargestellt werden soll.

Ein Beispiel: Sehen wir uns das Ganze an der Einheit „Newton“ für die Kraft an – diese Einheit wird im Basis-Lieferumfang bereits enthalten sein:

Soweit, so effizient. Doch wie gestaltet sich z.B. eine Einheit, die Sie ggf. selbst anlegen müssen, da sie in der D-SI-Definition nicht enthalten ist? Wir bedienen uns dazu der physikalischen Einheit „Nm“ für die Messgröße Drehmoment:

Durch Eingabe der Symbole „N“ und „m“ kann ein Einheitenkonfigurator, der die Einheiten „Newton“ und „Meter“ kennt, die daraus resultierende auf SI-Einheiten zurückgeführte Darstellung automatisch generieren und korrekt anlegen:

So ist es möglich, einen vollständigen Messwert (z.B. für einen Temperaturmesswert) mitsamt seiner physikalischen Einheit in der Notation des digitalen Einheitensystems und unter entsprechender Angabe der Messunsicherheit in Programmcode darzustellen:

<siTest:testData id="Ist-Wert Temperaturmessung">
		<si:real>
			<si:label>temperature</si:label>
			<si:value>21.05</si:value>
			<si:unit>\degreecelsius</si:unit>
			<si:expandedUnc>
				<si:uncertainty>0.50</si:uncertainty>
				<si:coverageFactor>2</si:coverageFactor>
				<si:coverageProbability>0.95</si:coverageProbability>
				<si:distribution>normal</si:distribution>
			</si:expandedUnc>
		</si:real>
	</siTest:testData>

Fazit

Effiziente Software-Systeme, die in der Lage sind, Messwerte mithilfe des digitalen Einheitensystems zu notieren, können zunächst menscheninterpretierbare Informationen wie „1 N“ ausgeben; das Besondere: Sie sind darüber hinaus in der Lage zu verstehen, was diese Einheit bedeutet und wie die Einheit umgerechnet werden kann. Solche Systeme, die das digitale SI-Einheitensystem verwenden, können die Messwerte aus dem digitalen Kalibrierschein (DCC) auslesen und verstehen, da in der XML-Schema-Definition des DCC die digitalen SI-Einheiten verwendet werden. Auf diese Weise können physikalische Einheiten digital interpretierbar verarbeitet werden und die entsprechenden Managementsystem-Prozesse leisten eine wirklich effiziente Unterstützung im Labor.