LabVIEW中测试测量数据的存储

这里说的测试测量数据是指配合NI的硬件，如PXI卡采集所得的测试测量数据。对其他的测试测量应用场景我还不熟悉。

NI原先是缺乏一个比较优秀的测试测量数据存储方案的，NI后来也意识到了这个问题，于是在德国收购了一家公司，这家公司专做数据存储（也包括显示、报表等），于是NI在数据的采集、存储、显示这方面的产品线已经比较齐全了。

NI现在主推的一个数据存储逻辑模型叫做TDM(Technical Data Management)，具体的方案可见：

NI TDM Data Model

这个模型的特点可以简单概括为：清晰的层次结构以及支持各层次的描述性信息。具体来讲，一个TDM模型的数据文件可以分为三层，分别为文件（File）、组（Group）和通道（Channel），在每个层次上，都有NI定义好的一些属性，同时，用户也可以自定义属性。

这样的一种数据模型很容易被理解和接受。比较符合实际的应用需求。比如用NI的采集卡采集电压数据。一块卡上一共8个通道。每个通道每次采集的数据都可以保存为一个“通道（channel）”，8个通道一次采集的数据可以组成一个组（group），每天采集一次，n天就形成n个组，每个组都有8个通道，所有的数据都写在同一个文件（file）里。其他卡采集的数据放在不同的文件中。

除了直接采集到的数据（可称之为Raw Data）之外，总要写点其他信息的，比如采集卡到底是什么型号，每次采集都是谁来完成，采集的是电压还是电流，单位是伏特还是千伏等等。这些信息就称为描述性信息（Meat Data）。这些信息写在别的文件里面总不太容易管理，最好写在一个文件中。因此TDM模型也支持将这些描述性信息写在同一个文件中。

注意一下，我在这里说的是TDM的“逻辑”模型，并不是指他的物理存储结构。在NI，有数种文件格式都支持TDM的模型，但是他们的物理存储方式大相径庭，这个以后再写。

这种TDM模型的测试测量数据文件，是NI软件平台中通用的文件，除了LabVIEW外，很多其他的NI软件产品都支持这种模型，比如DIAdem、CVI、Singal Express等等。

在LabVIEW中，分别有三套API支持TDM模型的数据文件，他们分别是：

Measurement File/Storage VIs/TDMS

（图片采自LabVIEW 8.5.1 Professional）

这三套API分别对应着三种应用的难易级别，由易而难。具体以后再介绍。

下次写一下我对TDM数据模型的看法（优缺点），以及简单介绍相关的文件格式。

在分析TDM模型的优劣势之前，我想最好先罗列一下一些数据文件格式的技术要求。

NI软件平台上针对于测试测量的数据，有很多不同的文件格式，其中有几种是支持TDM模型的。并不是说这些文件都能满足以下技术要求，我只是先罗列出来：

1）写文件速度必须要快。很多情况下需要一边采集数据一边就把数据写到

文件中，采集卡的速度已经相当快了，这时候瓶颈常常是在写文件这个步骤上。相反，读文件可能并没有如此高的要求。

2）向文件追加（append）数据的时候，速度要快，这个时候不能读取文件中的信息。这其实也是常用的一个use case，采集数据写入文件的动作可能经常要进行（比如在一个循环中），往往又是往同样的文件中写入信息。

3）写文件的速度不能与文件大小成正比。我们希望不管文件有多大，写文件的速度总是保持相对恒定，不能文件越大就写得越慢。

4）支持随机的读取。比如我想读文件中某个位置的某些内容，不能要求把这个位置之前的所有数据都先读出来（即读到内存中）。

5）支持分别读写描述性信息和原始数据。这是上一条的延伸，读描述性信息（meta data）的时候不要求把原始数据（raw data）读进来，同样，读原始数据的时候也不要求把描述性信息读进来，否则，势必影响读文件的速度。

6）对读文件的速度也有一定的要求。这个要求主要来自于搜索数据。无数浩瀚的数据，怎样才能快速的找到用户需要的数据，这一直是一个难题。

7）文件不能太大。存储同样的数据量，文件自然越小越好。

技术要求暂时就写这么多，其实总结起来，无非两点：1）快；2）方便。我们对照TDM的数据模型，对于“快速”，暂时看得不明显（以后可以谈谈为什么TDMS文件可以达到“快速的要求”），但是说它“方便”，还是可以理解的。

这个模型的设计完全是依照用户的应用实例。首先，它是分层次的。比如说我们需要测试汽车发动机的各个指标。我们用8个通道的采集卡采集发动机振动的数据，8个通道分别采集8个部位的振动，存到文件中，作为一个组

（group），组的名字就叫做“发动机振动”。我们还需要采集发动机的进气管、排气管压力，又作为一个组。还要采集发动机的温度，可能也用8个通道的采集卡采集8个部位的温度，每个部位的温度数据作为一个通道（channel）存到文件中，8个通道作为一个组，叫做“发动机温度”等等。我们可能会采集多次，其他参数都不变，只是数据每次都附加在文件的后面。我们有很多的测试工程师，每个工程师做的测试分别存成一个TDM模型的数据文件。可以发现，这样的三层结构还是很清晰的。这就好比用LabVIEW些程序，VI大了，就不知道怎么管理了，那就多用几层SubVI嘛。

其次，它具有描述性信息。比如可能需要把测试的日期、测试者的名字、测试的环境配置等信息写下来。有些描述性信息是针对“文件”这个层次的，比如测试者的姓名。有些信息可能针对“组”这个层次，比如采集的是“温度”，单位是“摄氏度”。有些信息则可能针对“通道”，比如采集的是发动机哪个部位的温度等等。描述性信息比较利于他人阅读文件，并且，在搜索文件数据的时候，可以派上大用场，可以先利用这些描述性信息进行定位。当然，这些信息最好能和“原始数据”（raw data）放在一起，要是放在两个文件中，一是难以对应起来，而是不利于维护。这也好比是写LabVIEW程序，你写的程序，别人也要能看到，没太多的好办法，就多写点注释吧。

这样的TDM模型也有其缺点。至少看起来有点复杂，同时有原始数据和描述性数据，还要实现那么多的技术要求，着实有点困难啊。其次，这个模型写下来就固定了，一共就3个层次，说到底在某个文件中也就2个层次，不能扩展，不像XML那样方便。我有时候就想要把数据写到一个“通道”中，我还非得先造一个“组”出来（其实可以不写，默认会造一个出来，但是逻辑结构上不能缺少）。还有其他限制条件，比如原始数据必须写在“通道”这个层次，不能写在“组”这个层次等等。

总体来讲，TDM数据模型利大于弊，比较适合测试测量领域的数据的存储，是一套不错的解决方案。

今天谈谈如何选择合适的文件格式。

在LabVIEW中可以使用的文件格式有好几种，争对于测试测量数据的文件格式也不少。每种文件格式都有自己的优缺点，很难说孰优孰劣。关键的问题在于要选择合适自己的文件格式。

那么，在选择具体的文件格式时，有哪些指标可以参考？

1）性能。测试测量数据的一个比较重要的use case就是要一边采集数据一边存储数据，NI现在采集数据的速度已经非常快了，性能的瓶颈往往是在存储数据到文件中去这个步骤上。当然，有些use case对于读取数据的性能也有要求，比如要做实时的数据分析等。因此，在选择合适的文件格式时，需要考虑性能的问题。

2）兼容性。采集数据、存储数据、分析数据，用的可能不是同一套软件，很有可能在不同的平台、不同的软件中完成这些不同的功能。那么就需要采用一种比较通用的文件格式。

打个比方，XML就是一种比较通用的文件格式。

3）支持的数据类型。并不是每种文件格式都支持所有的数据类型。有些可能不支持存储二维数组、不支持存储时间、日期等等，在选择文件格式时需要注意到这一点，以免将来带来不必要的麻烦。

4）是否方便使用。有些人可能喜欢定义一套自己的文件格式，对于高手来讲也未尝不可，但是对于一般的用户就需要考虑是否有这个必要。有些文件格式，在LabVIEW中已经有现成的、丰富的API，那就直接拿来用吧。

5）可维护性、可移植性。写完的文件很有可能将来还会修改，还可能会拿去给别人去修改。别人是否看得懂这样的文件？别人是否方便修改这样的文件？

6）文件大小。存储相同的信息量，当然文件越小越好，信息存储紧凑一点好。

当然还有其他很多方面的指标可以参考。暂时先说这些，以后还会有更深入的内容介绍。

针对于测试测量行业的数据存储，LabVIEW提供了数种不同的文件格式，先来介绍一下LVM格式。

LVM(LabVIEW Measurement File)总体来说是一种比较轻量级的文件格式。它基于ASCII编码，用一般的文本编辑器打开都能看懂。当然，这个特点优劣参半，非二进制代码的文件，总体来说性能较低，并且不够紧凑（即存储相同信息量，文件稍大）。所以，LVM文件格式适用于对性能、文件大小并不具有太高要求的情形。

左图显示的就是用普通的文本编辑器打开一个LVM文件的情形。可以看到

LVM文件还有一个缺点，就是header中的属性是固定的，仅通过LabVIEW的API并不能增加用户自定义的属性，这是一个限制。当然，不排除这样的情况：用户自己用文本编辑器打开LVM文件，向其中写入或者修改一些属性。

世上没有完美的文件格式。LVM文件格式也有其自己的优缺点，有其独特的应用条件。并不能根据某个单一的指标判断它是好是坏，使用时应先判断自己的应用要求，作出合适的选择。

今天先来谈谈Datalog文件，这种文件格式也有点年代了。基本上可以认为这种文件格式是二进制的。准确的讲，如果仔细研究，可以发现这种文件的内部结构比较奇怪。举个例子：如果往这个文件中存储3个int32的数字，用二进制的文本编辑器打开，可以看到内容类似于：

这个还比较还理解，前面是一些头文件，后面是1、2、3三个数字。但是如果写入a、b、c三个字符，情况就比较复杂了：

中间再省略若干行0。。。到文件的最后是：

由此可见，该文件格式对于不同的数据类型、不同的存储方法有不同的内部结构。我个人看来，对于后一种结构，还是有不少的冗余信息的。这种文件使用起来也不是太复杂，有一整套的API可以调用，具体的使用方法可以参考帮助文档。

总体来讲，这种文件格式，性能、使用的建议度、可读性均在中等水平，仅适用于LabVIEW软件。对于性能有一点要求，但要求不是很高的用户来说，可以采用该文件格式。

再介绍一种文件格式，在LabVIEW中就叫做“二进制文件(binary file)”，其实很多文件格式都是二进制的，包括刚才介绍的Datalog，以及以后要介绍的TDMS。为了区别于其他二进制文件，我们有时候叫这种二进制文件为“bytestream”。具体操作这种文件格式的API非常简单。

这种文件格式的性能非常高，使用起来也非常方便（就两个VI，一个负责写，一个负责读），但是数据的组织，也就是内部数据的结构（在这里无法透露具体的内部结构），可以说是比较差的。如果用户对于写入文件的性能要求比较高，但是并没有太多后续维护、管理数据的需求，可以考虑采用这种文件格式。接着介绍LabVIEW中的另外两种文件格式。首先是Bytestream。

这个文件格式说穿了就是二进制文件。就两个VI，分别是读和写。基本支持LabVIEW中的任何类型的数据。只要你在LabVIEW中能造出的数据，都可以用这种文件格式存储。可以猜测，其实这两个VI做的事情也比较简单，直接把LabVIEW在内存中的这部分数据写到文件中就行了，当然这样做的话，效率也比较高，因为没什么运算的步骤。但是也有部分缺点，比如直接把数据写到文件中也不见得好，真正的问题是如何管理这些数据。例如，读文件的时候也需要知道究竟这些文件存储了什么类型的数据，究竟存储在文件的什么位置等等。

总的来说，如果用户追求纯粹的写文件的速度，并且不在乎将来读文件是否遇到困难（其实如果一个文件只写不读那就没什么意义了），那么用这样的文件格式还是可以的。

接下来介绍TDM文件格式。

TDM文件是指后缀名为.TDM的文件。文件的逻辑存储模型遵循NI的TDM Data Model，三层结构。TDM文件主要分为两个物理文件，一个是主文件，后缀名为TDM，存储原始数据以及属性等信息；另一个是头文件，后缀名为TDX，主要存储属性信息，方便查找，作为一个索引文件。主文件是类似于XML结构的，而头文件是一个二进制文件，理由也很简单：头文件主要用来索引搜索数据，所以对读的速度有较高要求，因此作为二进制文件更合适。

对于TDM文件的操作，LabVIEW中主要通过Storage VIs来完成。TDM 的文件格式，我个人感觉，最大的优点在于对于数据的管理。以前介绍的文件格式，没有对数据的管理做太多的考虑。TDM文件格式分为三次结构并且可以加

入用户定制的属性，使用更为方便。举个通俗易懂的例子：很多人中午要带饭，放在饭盒里。普通的文件就是一个大杂烩，饭、菜混合放在一起，吃起来不方便并且看上去就杂乱；而TDM文件就像是有分隔的饭盒，饭菜可以分开放置，方便整洁。

随着NI在测试测量文件方面的进步，TDM的文件格式已经逐步被TDMS 文件格式取代，下次专门介绍TDMS。

终于写到TDMS了，千呼万唤始出来啊，其实所有前面的相关文章都是为了TDMS作铺垫。正是由于用户提出的种种需求以及其他种种文件格式的缺点，才有了TDMS的出现。

1. TDMS文件的逻辑格式

TDMS文件的逻辑格式遵循TDM三层结构，仍然是文件、通道组、通道三层。用户在使用时只需要关心这三层就行了。

2. TDMS文件API

TDMS文件格式基本上可以称为NI用在测试测量领域的通用数据文件格式，LabVIEW, CVI/LabWindows, Signal Express, DIAdem中都可以使用，也常看到在Excel, MatLab被中调用。TDMS最核心的内容都在一个dll中，用户如果安装了LabVIEW，就会发现在Program Files\National Instruments\Shared\TDMS文件夹中有个tdms.dll的文件。其他软件正是通过调用这个dll的API来操作TDMS文件的。

在LabVIEW中操作TDMS文件其实相当方便，有专门的TDMS面板，提供了TDMS绝大多数的功能。虽然我们一直说Write/Read Measurement Files, Storage VIs, TDMS分别面向初级、中级、高级的用户，但是我个人觉得LabVIEW中的TDMS用起来十分方便，即便是初级用户，也能很容易的上手。在面板上一共就10个SubVI，无论是什么样的数据类型，都可以用这样同一套SubVI，无需大量额外的编程工作。

这里可以简单介绍一下TDMS面板上的两个SubVI，我个人觉得十分有用。一个是“TDMS File Viewer”，当用户写完某个TDMS文件之后，就可以用这个SubVI来方便的查看文件的内容，只要输入TDMS文件的路径即可，运行VI 就会跳出一个Viewer的界面，可以查看数据、属性，并且可以根据数据简单的绘制出一些波形图。另外一个是“TDMS Defragment”，通常用户写完TDMS 文件之后，可能会发现这个文件非常大，那么这时就可以使用这个SubVI，可以大幅度的减小文件的size。

3. TDMS二进制文件

TDMS从设计之初就确定它必须是二进制的。二进制文件带来两个优点：第一，与一般的文本式文件相比，二进制文件通常比较小；第二，二进制文件读写通常比较快。这两个都是其他二进制文件都具备的优点，就不再多说了。

4. TDMS头文件

用户写完TDMS文件之后，会发现硬盘上其实有两个TDMS文件，一个是.tdms，另一个是.tdms_index文件，我们通常把前者称为主文件或者数据文件，而把后者称为头文件或者索引文件。头文件与主文件相比，最大的区别就是把主文件中的raw data都去掉了，只留下属性等信息。这样做，有两个目的，第一，可以使得读文件加快速度，并且支持随机读取文件数据，这个稍后再解释，用户看完后面的内容就可以理解。第二，可以使得某些软件的搜索TDMS文件功能加快。比如在DIAdem中搜索TDMS文件，可以根据文件名、通道组名、通道名（其实这些也是属性），或者其他某些属性进行搜索，这个时候，仅将TDMS的头文件载入进行搜索，其速度远远比将TDMS主文件载入搜索快得多。

5. TDMS的内部结构

TDMS文件的内部结构，也就是物理结构，可以在这里找到原文。一般的用户并不需要了解这方面的知识就可以方便的使用TDMS文件。在这里介绍这个内部结构，是为了更好的解释TDMS文件格式的优点。

TDMS内部结构的核心概念是segment，如下图。为了避免混淆，在这里必须澄清的是，这个segment的概念与TDM的三层结构（即逻辑结构）没有任何对应的关系，也就是说，一个通道可能对应着多个segment，一个segment 中也可能有多个通道。segment是什么意思？我们在写TDMS文件的时候，数据本来可能存放在内存中，那么总要往硬盘上写这些数据的，每次往硬盘上写（flush to disk）就会产生这样一个segment。同样，我们在读TDMS文件的时候，也是一个segment一个segment的把内容读出来。

再稍微深入介绍一下这个segment中的内容。一开始有一些头信息，比如这个segment中是否含有meta data，是否含有raw data，version是多少。下面的东西就很重要了，有个“next segment offset”的信息，指向下一个segment的起始位置，这个有什么用呢？比如我要读某个通道的数据，发现这个segment中并不包含这个通道的内容，就可以使用这样的信息直接跳到下个segment中看下个segment是否有要找的信息。同样，还有一个“raw data offset”的信息，比如用户只想读raw data，并不关心属性之类的信息，那么这个“raw data offset”的信息就派上用场了。说到这里，就可以明白，TDMS是怎样支持Random access，怎样支持独立的读属性信息和raw data的信息。

此外，这个segment还有一个极为重要的特点。我们每次写数据，每次往TDMS文件中flush to disk的时候就在文件的后面添加这样一个segment，而不去关心之前的segment中包含了什么样的信息。这个特点非常关键，这就可以使得我们写文件的速度非常快，我们并不关心之前文件中包含了什么信息，也就使得我们写TDMS文件的速度并不和TDMS文件的大小成正比或者有任何关系。

6. TDMS文件格式的优点

我在以前的文章中提到几个数据文件格式的技术要求，我们现在再来回顾一下，看看TDMS文件是如何实现这些技术要求的，这样也就能看出TDMS文件的优点来。

1）写文件速度必须要快——通过segment实现以及二进制。

2）向文件追加（append）数据的时候，速度要快——segment。

3）写文件的速度不能与文件大小成正比——segment。

4）支持随机的读取——segment以及头文件。

5）支持分别读写描述性信息和原始数据——segment以及头文件。

6）对读文件的速度也有一定的要求——segment以及头文件。

7）文件不能太大——二进制。

7. 其他

TDMS文件格式目前（LabVIEW 8.5）只支持Windows和PharLap（一种实时操作系统）平台上。不过我还看到一个基于VI的TDMS API，这个完全基于LabVIEW，既然LabVIEW能在其他平台上工作，那么这个小工具也能在其他平台上工作。当然，效率、性能的会差很多了。

通常总有人拿TDMS文件格式和一般的基于Windows API文件流操作比较，然后会说TDMS比那样的Win32 streaming API慢嘛，是不是TDMS不行？比如在某些磁盘阵列的配置下，Win32 streaming API可以达到

650MB/S，而TDMS只能600MB/S左右。我在这里需要澄清的是，TDMS 在保持着数据良好逻辑结构（TDM的三层结构）、良好的数据管理的前提下，还能保持着这样高速的性能，这才是TDMS最大的优点。Win32 streaming API 只是纯粹的追求速度（也仅比TDMS快5-10%左右），并不能将测试测量的数据良好的组织好、管理好，用户如果片面的追求速度而不管写入文件的数据如何保存如何管理，那就有点得不偿失了。

当然，TDMS文件也并不完美，同样存在着种种缺点。比如不能支持方便的删除某个通道的功能，目前还不支持其他操作系统等等。相信将来都会有改善的。

最后，用一个不是很恰当的例子来结束这篇文章。测试测量数据的文件格式，有很多种，文件格式就像我们中午带饭的饭盒一样。其他的数据文件格式就是把饭菜都放在一起，吃起来不方便（速度慢），而且味道都混杂在一起（组织不好）；而TDMS文件格式就像是内部有分隔的饭盒，不同的饭菜分开存放，吃起来又方便（速度快）味道又好（组织良好）。