The TDM+ Data Model

The TDM data model is derived from an international standard called ASAM ODS. ASAM is the “Association for the Standardization of Automation and Measuring Systems” and ODS stands for “Open Data Services”.  National Instruments, as one of the co-founders of ASAM and an active member of the ASAM ODS working group, is bringing the ASAM ODS standard to the measurement industry.  ASAM ODS defines the storage of measurement data, for instance, in an Oracle or mixed-mode server and a Corba-based API for data access. The major benefit is the definition of a so-called base data model, which allows you to add semantic (meta-) information to the data stored in the database.

The ASAM ODS data model provides templates, or base objects, which can be used to define a user specific data model: the application model. The templates are grouped by the different aspects of data: Environment, Administration, Measurements, Descriptive Data, Dimensions and Units, Security and Other.

^{Figure 1: An overview of the ASAM ODS data model.} 

The major objective of ASAM ODS is to store and organize measurement data, making Measurements the center of the ASAM ODS base model.

Working with ASAM ODS requires the definition of a so called application model derived from the ASAM ODS base model. There are two major design alternatives: the “object approach” and the “property approach”.

In the “object approach” meta data is grouped into several objects, in most cases picked from the Descriptive Data group combined with several AoAny derived objects. The advantage is that information can be composed into logical objects to avoid redundancies. Otherwise this often requires requesting several objects (tables) to generate a report. An example of the “object approach” is the openMDM data model.

The alternative to the object approach is the “property approach”. In the “property approach” additional information (properties, name-value pairs) is directly added to the measurement objects and the surrounding test and channel objects. The advantage of the “property approach” is that the necessary information is stored close to the measurement and can be retrieved easily. The drawback is the added redundancy, possibly resulting in a bigger database size. An example of the “property approach” is the TDM data model.

While both approaches are obviously different, the result as presented to the user is comparable. For instance, the name of a UnitUnderTest (UUT) can be retrieved as measurement.uut.name (name is stored on a uut object referenced by the measurement object) in the “object approach” and as measurement.uut_name (uut name is directly attached to the measurement object). In both cases the information may presented to the user as UUTName.

The TDM data model is designed to store measurement data. It derives from the ASAM ODS base model, follows the “property approach” and focuses on minimum complexity by concentrating on Measurements.

^{Figure 2: The TDM model simplifies the complex ASAM ODS data model.}

The three-level hierarchy (root, group, and channel) allows the organization of measurement channels into groups and ordering the different groups under a single root. On each of the three levels you can add an unlimited number of custom-defined properties. Translating the TDM data model to the ASAM ODS base model, this means that root is derived from AoTest, group from AoMeasurement, and channel from AoMeasurementQuantity.

The TDM data model is perfectly suited for storing measurement data, making it searchable using DataFinder, and using it to work within the DIAdem environment. Starting with DataFinder Server Edition 2013, DataFinder now also allows accessing the indexed data through its ASAM ODS Corba API.

ASAM ODS requires for each channel (AoMeasurementQuantity) to provide unit information (Dimensions and Units), allowing to perform unit conversion on the server side. While DIAdem has a built-in unit catalog, and therefore does not depend on server-side unit conversion, most other ASAM ODS clients have a need for it. This is why TDM+ adds Dimensions and Units to the data model. The resulting unit conversion in DataFinder is realized by mapping a DIAdem unit catalog to the ASAM ODS data model.

Another advantage of the TDM+ data model is that it can be used out-of-the-box while still providing the ability to change the model definition. In many existing ASAM ODS solutions the definition of the data model often takes several months and changing the data model afterwards requires more effort, whereas the pre-defined TDM+ data model can be changed easily at run-time by “optimizing custom properties”.

One more piece of flexibility of the TDM+ data model is the custom-defined test hierarchy derived from the existing (meta) data at run-time.

^{Figure 3: The TDM+ data model adds the benefits of a unit catalog.}

While adding properties and using a unit catalog sounds straight forward, a custom-defined test hierarchy of arbitrary depth derived from the existing (meta) data sounds a bit abstract. To get a better idea of how it works, let’s describe it with an example:
Consider measurement files with the properties “Test_Name” and “Test_Operator” on the root (file) level. Instead of viewing the data from the file system’s folder perspective, I would like to navigate my data from “Test_Name” over “Test_Operator” and finally to the measurement data. To do so, “Test_Name” is defined as the first level of the test hierarchy and “Test_Operator” as the second, resulting in the following tree view:

^{Figure 4: The property approach of the TDM+ data model allows you the flexibility to reorganize your data view at any time.}

You can use any number of text properties of the root (file) or group level to define the test hierarchy. Any ASAM ODS savvy clients can navigate over the defined test hierarchy of the TDM+ data model.

To conclude, SystemLink TDM DataFinder Module with the TDM+ data model adds additional functionality on top of TDM. TDM+ is an ASAM ODS application model following the “property design approach”. Properties can easily be added at run-time by “optimizing” custom properties. Additionally a custom-defined test hierarchy can be applied based on the existing meta data. Furthermore, the integrated (DIAdem) unit catalog allows server-side unit conversion. Through DataFinder’s ASAM ODS Corba API all this functionality is available out-of-the-box for all ASAM ODS client software, including NI DIAdem.

• Learn the basics of ASAM ODS
  
• Learn how to set up an ASAM ODS server based on the TDM+ data model