LabVIEW中测试测量数据的存储（2）

在分析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数据模型利大于弊，比较适合测试测量领域的数据的存储，是一套不错的解决方案。