Das Datenmodell TDM+

Das TDM-Datenmodell ist vom internationalen Standard namens ASAM ODS abgeleitet. ASAM steht für „Association for the Standardization of Automation and Measuring Systems“ (Verein zur Förderung der internationalen Standardisierung von Automatisierungs- und Messsystemen) und ODS für „Open Data Services“ (Offene Datendienste).  National Instruments hat als einer der Mitbegründer von ASAM sowie als aktives Mitglied der ASAM-ODS-Arbeitsgruppe den ASAM-ODS-Standard in die Messtechnikbranche eingebracht.  ASAM ODS definiert das Speichern von Messdaten beispielsweise auf einem Oracle- oder Mischmodus-Server sowie eine CORBA-basierte (Allgemeine Architektur für Vermittler von Objekt-Nachrichten) API für den Datenzugriff. Der wesentliche Vorteil ist die Definition des sogenannten Basisdatenmodells, mit dem Anwender den in der Datenbank gespeicherten Daten semantische (Meta-)Informationen hinzufügen können.

Das ASAM-ODS-Datenmodell stellt Vorlagen bzw. Basisobjekte bereit, die für die Definition eines anwenderspezifischen Datenmodells eingesetzt werden können: das Anwendungsmodell. Die Vorlagen sind nach den unterschiedlichen Aspekten der Daten gruppiert: Environment/Umgebung, Administration/Verwaltung, Measurements/Messungen, Descriptive Data/Beschreibende Daten, Dimensions and Units/Maße und Einheiten, Security/Sicherheit und Others/Andere.

^{Abbildung 1: Übersicht über das ASAM-ODS-Datenmodell} 

ASAM ODS ist in der Hauptsache dazu gedacht, Messdaten zu speichern und zu organisieren, wodurch Measurements/Messungen zum zentralen Bestandteil des ASAM-ODS-Basismodells werden.

Das Arbeiten mit ASAM ODS erfordert die Definition eines sogenannten Anwendungsmodells, das vom ASAM-ODS-Basismodell hergeleitet wird. Zwei wesentliche Entwurfsalternativen bestehen: der „Objektansatz“ und der „Eigenschaftenansatz“.

Beim „Objektansatz“ werden Metadaten zu verschiedenen Objekten zusammengefasst. Diese werden in den meisten Fällen aus der Gruppe Descriptive Data/Beschreibende Daten in Kombination mit etlichen von AoAny abgeleiteten Objekten ausgewählt. Der Vorteil liegt darin, dass Informationen zu logischen Objekten zusammengestellt werden können, um Redundanzen zu vermeiden. Andernfalls ist es oft erforderlich, dass verschiedene Objekte (Tabellen) zum Erzeugen eines Berichts abgefragt werden. Ein Beispiel des „Objektansatzes“ ist das openMDM-Datenmodell.

Die Alternative zum Objektansatz ist der „Eigenschaftenansatz“. Beim Eigenschaftenansatz werden Zusatzinformationen (Eigenschaften, Name/Wert-Paare) direkt zu den Messobjekten sowie den umgebenden Test- und Kanalobjekten hinzugefügt. Der Vorteil des Eigenschaftenansatzes besteht darin, dass die notwendigen Informationen nahe der Messung gespeichert werden und sich leicht abrufen lassen. Nachteilig ist die zusätzliche Redundanz, die möglicherweise eine deutlich größere Datenbank zur Folgen haben kann. Ein Beispiel für den Eigenschaftenansatz ist das TDM-Datenmodell.

Zwar sind beide Ansätze offensichtlich verschieden, das dem Anwender dargestellte Ergebnis ist jedoch vergleichbar. So kann beispielsweise der Name eines UnitUnderTest/Prüflings (UUT) als measurement.uut.name (Name wird in einem uut-Objekt gespeichert, auf das vom Messobjekt verwiesen wird) im „Objektansatz“ und als measurement.uut_name (uut-Name ist direkt mit dem Messobjekt verbunden) abgerufen werden. In beiden Fällen können die Informationen dem Anwender als UUTName dargestellt werden.

Das TDM-Datenmodell ist für das Speichern von Messdaten bestimmt. Es leitet sich vom ASAM-ODS-Basismodell ab, folgt dem „Eigenschaftenansatz“ und zielt auf geringste Komplexität, indem Measurements/Messungen den Fokus bilden.

^{Abbildung 2: Das TDM-Modell vereinfacht das komplexe ASAM-ODS-Datenmodell.}

Die dreigliedrige Hierarchie (Verzeichnis, Gruppe und Kanal) ermöglicht das Gruppieren von Messkanälen sowie das anschließende Organisieren der verschiedenen Gruppen unter einem einzigen Verzeichnis. Auf jeder der drei Ebenen kann eine unbegrenzte Anzahl benutzerdefinierter Eigenschaften hinzugefügt werden. Ein Übertragen des TDM-Datenmodells in das ASAM-ODS-Basismodell bedeutet, dass das Verzeichnis von AoTest, Gruppe von AoMeasurement und Kanal von AoMeasurementQuantity hergeleitet wird.

Das TDM-Datenmodell ist ideal für das Speichern von Messdaten, denn damit werden sie über DataFinder durchsuchbar. Zudem kann es für Aufgaben innerhalb der Umgebung DIAdem eingesetzt werden. Ab DataFinder Server Edition 2013 erlaubt DataFinder den Zugriff auf die indizierten Daten über die ASAM-ODS-CORBA-API.

Bei ASAM ODS ist es für jeden Kanal (AoMeasurementQuantity) erforderlich, Einheiteninformationen (Dimensions and Units/Maße und Einheiten) bereitzustellen, sodass eine Einheitenumrechnung serverseitig erfolgen kann. DIAdem verfügt über einen integrierten Einheitenkatalog und ist daher nicht von einer serverseitigen Umrechnung abhängig. Die meisten anderen ASAM-ODS-Clients benötigen sie allerdings. Deshalb erweitert TDM+ das Datenmodell um Dimensions and Units/Maße und Einheiten. Die daraus resultierende Einheitenumrechnung in DataFinder wird durch Abbilden eines DIAdem-Einheitenkatalogs auf das ASAM-ODS-Datenmodell umgesetzt.

Ein weiterer Vorteil des Datenmodells TDM+ liegt darin, dass es direkt ab Lieferung verwendet werden kann. Dennoch ist die Möglichkeit gegeben, die Modelldefinition zu ändern. Bei vielen bestehenden ASAM-ODS-Lösungen werden für die Definition des Datenmodells oft mehrere Monate benötigt und das spätere Ändern des Modells erfordert einen höheren Aufwand. Das vordefinierte Datenmodell TDM+ hingegen kann leicht während der Ausführung verändert werden, indem die „optimierte Zusatzeigenschaften“ verwendet werden.

Weitere Flexibilität bietet das Datenmodell TDM+ aufgrund der benutzerdefinierten Testhierarchie, die von den bestehenden (Meta-)Daten zur Laufzeit hergeleitet wird.

^{Abbildung 3: Das Datenmodell TDM+ stellt die Vorteile eines Einheitenkatalogs bereit.}

Das Hinzufügen von Einheiten und das Verwenden eines Einheitenkatalogs klingt unkompliziert. Eine benutzerdefinierte Testhierarchie arbiträrer Tiefe hingegen, die von den bestehenden (Meta-)Daten hergeleitet wird, klingt etwas abstrakt. Um dies zu verdeutlichen, dient das folgende Beispiel:
Betrachtet werden Messdateien mit den Eigenschaften „Test_Name“ und „Test_Operator“ auf Verzeichnis(datei)ebene. Statt die Daten aus der Ordnerperspektive des Dateisystems einzusehen, soll auf die Daten angefangen bei „Test_Name“ über „Test_Operator“ und schließlich Messdaten zugegriffen werden. Dazu wird „Test_Name“ als erste Ebene der Testhierarchie und „Test_Operator“ als zweite definiert. Daraus ergibt sich folgende Baumansicht:

^{Abbildung 4: Der Eigenschaftenansatz des Datenmodells TDM+ sorgt dafür, dass Anwender die Datenansicht jederzeit flexibel reorganisieren können.}

Die Testhierarchie kann mit einer belieben Anzahl von Texteigenschaften des Verzeichnisses (der Verzeichnisdatei) oder der Gruppenebene definiert werden. Alle ASAM-ODS-fähigen Clients können durch die definierte Testhierarchie des Datenmodells TDM+ navigieren.

Das SystemLink TDM DataFinder Module erweitert also TDM mit dem Datenmodell TDM+ um zusätzliche Funktionalität. Bei TDM+ handelt es sich um ein ASAM-ODS-Anwendungsmodell nach dem „Eigenschaftenentwurfsansatz“. Eigenschaften lassen sich während der Ausführung leicht ergänzen, indem Zusatzeigenschaften „optimiert“ werden. Zusätzlich kann eine benutzerdefinierte Testhierarchie basierend auf den bestehenden Metadaten angewendet werden. Der integrierte Einheitenkatalog (DIAdem) ermöglicht darüber hinaus eine serverseitige Einheitenumrechnung. Durch die ASAM-ODS-CORBA-API von DataFinder ist diese Funktionalität sofort einsatzbereit für jegliche ASAM-ODS-Client-Software verfügbar, einschließlich NI DIAdem.

• Grundlagen von ASAM ODS
  
• Einen ASAM-ODS-Server basierend auf dem Datenmodell TDM+ einrichten